 1-Feb-84 11:42:47-MST,961;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 1 Feb 84 11:42:42-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  1 Feb 84 3:42 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  1 Feb 84 3:31 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 1 Feb 84 0:23-PST
Date: 30 Jan 84 19:42:26-PST (Mon)
To: info-cpm@brl
From: hplabs!hao!kpno!grandi@ucb-vax
Subject: How does a VT180 send break?
Article-I.D.: kpno.291

I'm trying to get my DEC VT180 to send out a break under program
control.  In other words, has anyone a working modem7 SENDBRK routine
for the VT180?  I know the machine is capable of it since it nicely
breaks in terminal, but my ignorant attempts to make the 8251 do my
bidding have been dismal failures.
-- 
Steve Grandi,  Kitt Peak National Observatory, Tucson, AZ, (602) 325-9228
      {arizona,decvax,hao,ihnp4,astrovax,utastronomy,amd70}  !kpno!grandi
 1-Feb-84 13:14:36-MST,793;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 1 Feb 84 13:14:32-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  1 Feb 84 13:48 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  1 Feb 84 8:58 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 1 Feb 84 5:54-PST
Date: 28 Jan 84 0:46:05-PST (Sat)
To: info-cpm@brl
From: pur-ee!uiucdcs!parsec!graham@ucb-vax
Subject: Re: MDM719 now available - (nf)
Article-I.D.: uiucdcs.5221

#R:sri-arpa:-1585500:parsec:48000006:000:193
parsec!graham    Jan 27 18:42:00 1984

How do those of us not on the ARPANET get stuff from this wondrous SIMTEL20??

Marv Graham; ConVex Computer Corp.
{allegra,ihnp4,uiucdcs,ctvax}!parsec!graham
O: (214)669-3700  H: (214)931-7924
 2-Feb-84 08:46:22-MST,614;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 2 Feb 84 08:46:17-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  2 Feb 84 3:18 EST
Received: From Sumex-Aim.ARPA by BRL via smtp;  1 Feb 84 22:33 EST
Date: Wed 1 Feb 84 19:40:32-PST
From: Leslie Zatz <ZATZ@SUMEX-AIM.ARPA>
Subject: MDM???
To: INFO-CPM@BRL.ARPA

   Can someone let us know what is going on with the MDM
series? It looks like MDM720 has come out from I. Hoff
but there had been a previous posting indicating that
R. Fowler was putting out MDM720. Are these the same?
-------
 2-Feb-84 08:49:07-MST,1064;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 2 Feb 84 08:49:03-MST
Received: From Sri-Kl.ARPA by BRL-VGR via smtp;  2 Feb 84 7:32 EST
Date: Thu 2 Feb 84 04:34:28-PST
From: Jon L. Spear <OTHB@SRI-KL.ARPA>
Subject: Z-80, CP/M Emulator for Macintosh?
To: Info-CPM@BRL-VGR.ARPA, info-micro@MIT-MC.ARPA

	I am not sure what possessed me to do it, but I just
bought an Apple Macintosh.  Nifty machine, but a dirth of
software -- no programming language available yet (to users).

	Has anyone done Z80 or 8080 emulators for the 68000
so that they could run the thousands of CP/M programs in the
world?  I am not too concerned with the obvious media problems.
The question is whether it is feasible to write an emulator
that would fit in the 128K RAM, allow a reasonable size TPA,
and run CP/M programs at a speed close to that of a 2MHZ Z-80.
(emulated on the 8MHZ 68000).

	With a Z-80 costing only a few bucks, a hardware solution
might be much more reasonable.

Comments?

--Jon
-------
 2-Feb-84 08:49:15-MST,569;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 2 Feb 84 08:49:12-MST
Received: From Sumex-Aim.ARPA by BRL-VGR via smtp;  2 Feb 84 7:58 EST
Date: Thu 2 Feb 84 05:00:26-PST
From: Sam Hahn <SHahn@SUMEX-AIM.ARPA>
Subject: Re: Z-80, CP/M Emulator for Macintosh?
To: OTHB@SRI-KL.ARPA
cc: Info-CPM@BRL-VGR.ARPA, info-micro@MIT-MC.ARPA
In-Reply-To: Message from "Jon L. Spear <OTHB@SRI-KL.ARPA>" of Thu 2 Feb 84 04:58:33-PST

Are you sure the 68k is actually running at 8Mhz, and not 5 Mhz, as I thought?
-------
 2-Feb-84 08:53:35-MST,1467;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 2 Feb 84 08:53:31-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  2 Feb 84 9:41 EST
Received: From Radc-Tops20.ARPA by BRL via smtp;  2 Feb 84 9:35 EST
Date: Thu 2 Feb 84 09:37:30-EST
From: Gern <GUBBINS@RADC-TOPS20.ARPA>
Subject: New MAILING-LIST:  INFO-HZ100
To: zellich@OFFICE-3.ARPA
cc: INFO-HZ100@RADC-TOPS20.ARPA, INFO-MICRO@BRL.ARPA, INFO-CPM@BRL.ARPA

To whom it may concern,

The INFO-HZ100 mailing list is now a reality.

INFO-HZ100 is a forum for discussion concerning topics related to
the Zenith Z-100 (Heath H-100) family of professional desktop
computers.   Messages are collected into digests and distributed
as the volume of mail dictates.

Periodically, useful knowledge and items generated from the digests
and other random sources will be edited into a newsletter for
distribution to both network and non-network interested groups.

Any comments, suggestions, help, knowledge, software, ideas, file space,
etc., would be greatly appreciated.

Future plans are to have a library of Z-100 software, and digest &
newsletter archives.

All requests to this list should be directed to:
                      INFO-HZ100-REQUEST@RADC-TOPS20

Submissions to the digest should be directed to:
                          INFO-HZ100@RADC-TOPS20

Coordinator: Dave Gubbins (Gern)  <GUBBINS@RADC-TOPS20>

-------
 2-Feb-84 10:22:24-MST,647;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 2 Feb 84 10:22:14-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  2 Feb 84 11:28 EST
Received: From Parc-Maxc.ARPA by BRL via smtp;  2 Feb 84 11:20 EST
Date: Thu, 2 Feb 84 08:23 PST
From: DHead.es@PARC-MAXC.ARPA
Subject: Public domain for -86
To: INFO-CPM@BRL.ARPA

Does anyone know if much is being done in the area of RCPM systems and
public domain software for CP/M-86? I saw a couple of SIG/M disks with
translations of stuff like Vfiler, but are there any more sources? Any
pointers would be appreciated.

~~Dave~~

 2-Feb-84 10:22:37-MST,898;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 2 Feb 84 10:22:31-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  2 Feb 84 11:27 EST
Date:     Thu, 2 Feb 84 11:19:50 EST
From:     Rick Conn <rconn@brl>
To:       info-cpm@brl
Subject:  SYSLIB 3.0

	The first step in the creation of ZCPR3 is now complete (at least
for the time being).  This is the creation of SYSLIB 3.0 from SYSLIB 2.7.
The following message is a rather complete documentation of the differences
between these two.  If anyone knows of any bugs I have not corrected or
has any ideas as to what additional features should go into SYSLIB 3.0,
please drop me a message.

	Note that Z3LIB, which contains the ZCPR3-specific utilities,
is now a separate library from SYSLIB 3.0.  Z3LIB is still evolving and
details will be released later on it.

		Rick
 2-Feb-84 10:48:20-MST,11371;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 2 Feb 84 10:47:50-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  2 Feb 84 11:28 EST
Date:     Thu, 2 Feb 84 11:21:19 EST
From:     Rick Conn <rconn@brl>
To:       info-cpm@brl
Subject:  SYSLIB 2.7 and SYSLIB 3.0 differences

                            SYSLIB 3.0 Upgrade Notes



                           Notes on Changes in SYSLIB
                          From SYSLIB 2.7 to SYSLIB 3.0

                                  Richard Conn
                                February 1, 1984

             This  document  summarizes the changes made to SYSLIB  under 
        Version 3.0 from the previous version,  2.7.  SYSLIB 3.0 consists 
        of over 210 routines in over 150 modules, each module residing in 
        a separate file.

        A.  Changes Made to Existing Routines and Modules

             1. All of the ZCPR2-specific routines have been removed from 
        SYSLIB.  These are now placed in a separate library and have been 
        updated to reflect ZCPR3 rather than ZCPR2.   SYSLIB 2.7 is still 
        to be used to support ZCPR2, while SYSLIB 3.0 and Z3LIB are to be 
        used to support ZCPR3.

             2.  Disk-Based Named Directories are not supported in Z3LIB.  
        The  ZDNAME  routine  has  been  omitted,  and  ZCPRQ2,  ZFNINIT, 
        ZDNFIND,  and  ZFNAME  have been changed to remove  any  features 
        relating  to  disk-based named directories.   Memory-based  named 
        directories  are  still  supported.   Modules:   SZFNAME.MAC  and 
        SZGPINS.MAC  changed and now named Z3FNAME.MAC  and  Z3GPINS.MAC.  
        Also,  to test the value of this change,  XD was reassembled, and 
        the  new COM file is 11 blocks (almost 1.5K) smaller than the old 
        version.

             3.   All  math routines have been broken out  into  separate 
        modules as appropriate.  There are now 12 math modules in SYSLIB.  
        Modules:  SMATH.MAC removed, SMTHnn (01 <= nn <= 12) added.

             4.   A  bug  has been corrected in EVAL10  which  prohibited 
        accurate  processing  of numbers greater than  8  bits.   Module:  
        SEVAL1.MAC.

             5.  Version Number is now 3.0.  Module:  SVERSION.MAC.

             6.  A  bug has been corrected in DIRF and DIRFS in which the 
        proper  return  code  was  not  returned  in   A/PSW.    Internal 
        documentation was also cleaned up.  Also, the SDIR.MAC module was 
        broken up into a set of independent modules, named SDIRxx.MAC (00 
        <= xx <= 10), SDIR.MAC, SDIRHDR.LIB, and SDIRBF.MAC.

             7.   The  SUD module was broken up into SUD1.MAC,  SUD2.MAC, 
        and SUD3.MAC.

             8.  The routines F$MAKE, F$READ, and F$WRITE were changed to 
        return  proper  PSW  flag settings.   Now  return  codes  can  be 
        examined  without  an  ORA A after the  routine  call.   Modules:  
        SFMAKE.MAC, SFREAD.MAC, SFWRIT.MAC.




                                                           Page 1





                            SYSLIB 3.0 Upgrade Notes



             9.   The  following  SYSLIB routines have been  modified  or 
        improved:

                  Routine   Module         Routine   Module
                  -------   ------         -------   ------
                  PADC      SPADC          PA2HC     SPA2HC
                  PHL4HC    SPHL4HC        PHL5DC    SPHL5DC
                  PHLDC     SPHL5DC        LADC      SLADC
                  LA2HC     SLA2HC         LHL4HC    SLHL4HC
                  LHL5DC    SLHL5DC        LHLDC     SLHLDC



        B.  New SYSLIB Routines and Modules

             1.  The following numeric output routines have been added:

             Routine   Module    Function
             -------   ------    --------
             LAFDC     SLAFDC    Print A as Floating Decimal to LST:
             LHLFDC    SLHLFDC   Print HL as Floating Decimal to LST:

             MAFDC     SMAFDC    Print A as Floating Decimal to Memory
             MHLFDC    SMHLFDC   Print HL as Floating Dec to Memory

             PAFDC     SPAFDC    Print A as Floating Decimal to CON:
             PHLFDC    SPHLFDC   Print HL as Floating Decimal to CON:

             SA2HC     SSA2HC    Print A as 2 Hex Chars to S Output*
             SA3DC     SSADC     Print A as 3 Dec Chars to S Output
             SADC      SSADC     Print A as Decimal Chars to S Output
             SAFDC     SSAFDC    Print A as Floating Dec to S Output
             SHL4HC    SSHL4HC   Print HL as 4 Hex Chars to S Output
             SHL5DC    SSHL5DC   Print HL as 5 Dec Chars to S Output
             SHLDC     SSHL5DC   Print HL as Dec Chars to S Output
             SHLFDC    SSHLFDC   Print HL as Floating Dec to S Output

        *  S  Output is the new SYSLIB  Switched  Output  feature,  where 
        output  can be selected to go to any one of four combinations  of 
        CON: or LST: dynamically.

             2.  The following S-Output Routines have been added:

             Routine   Module    Function
             -------   ------    --------
             SCOUT     SSCOUT    Print Char A with Ctrl Char Processing
                                      to S Output
             SCRLF     SSCRLF    Print New Line to S Output
             SCTLFL    SSCTLFL   Switch Control Flag
             SOUT      SSOUT     Print Char A to S Output
             SPRINT    SSPRINT   Print String at Ret Adr to S Output
             SPSTR     SSPSTR    Print String at HL to S Output




                                                           Page 2





                            SYSLIB 3.0 Upgrade Notes



        B.  New SYSLIB Routines and Modules, Con't

             3.   The  following Byte-Oriented File I/O  routines,  which 
        support variable-sized buffers for blocking/deblocking, have been 
        added.  All are in the SFXIO.MAC Module.

             Routine   Function
             -------   --------
             FXI$OPEN  Open File for Input
             FXI$CLOSE Close Input File
             FXO$OPEN  Open File for Output
             FXO$CLOSE Close Output File
             FX$GET    Get Byte from Input File
             FX$PUT    Put Byte to Output File

             4.  An F$SIZE routine has been added which computes the file 
        size of a file to the nearest K, ignoring grouping factors.  Just 
        the  first  12 bytes of the FCB are passed  to  F$SIZE.   Module:  
        SFSIZE.MAC.

             5.   A set of routines have been added for character testing 
        and  string  parsing  functions.   Each is contained in  its  own 
        module, which is named after it with an S prefix.  These routines 
        are:

             Routine   Function
             -------   --------
             ISALNUM   Is Alphanumeric
             ISALPHA   Is Alphabetic
             ISCTRL    Is Control
             ISDIGIT   Is Digit
             ISGRAPH   Is Graphic
             ISHEX     Is Hexadecimal
             ISPRINT   Is Printable
             ISPUN     Is Punctuation
             ISSP      Is Space Char

             SKNPUN    Skip Over Non-Punctuation Chars
             SKNSP     Skip Over Non-Space Chars
             SKPUN     Skip Over Punctuation Chars
             SKSP      Skip Over Space Chars

             6.   New dynamic buffer allocation routines have been added.  
        Both are in the SALLOC.MAC Module.

             Routine   Function
             -------   --------
             ALLOC     Allocate N Bytes from Dynamic Buffer
             IALLOC    Specify Bounds of Dynamic Buffer







                                                           Page 3





                            SYSLIB 3.0 Upgrade Notes



        B.  New SYSLIB Routines and Modules, Con't

             7.  The following character I/O routines have been added:

             Routine   Module    Function
             -------   ------    --------
             BIN       SBIN      Input CON: Char via BDOS
             BIST      SBIST     Input CON: Char Status via BDOS
             BOUT      SBOUT     Output Char to CON: via BDOS

             CAPIN     SCAPIN    Input CON: Char and Capitalize
             CAPINE    SCAPIN    CAPIN and Echo

             8.   There are now eight SYSTEST programs,  designed to test 
        the   various  features  of  SYSLIB  3.0.    These  programs  are 
        SYSTEST.MAC and SYSTESTn.MAC (1 <= n <= 7).

             9.   The  following  FCB File Name and Type Output  routines 
        have been added:

        CON:   LST:   Switched  Memory    Function
        ----   ----   --------  ------    --------
        PFN1   LFN1   SFN1      MFN1      12 Chars, Embedded Spaces
        PFN2   LFN2   SFN2      MFN2      N-Chars, No Spaces
        PFN3   LFN3   SFN3      MFN3      12 Chars, Trailing Spaces

             Each routine is in its own module,  which is named after the 
        routine but is prefixed with an S (ie, PFN1 is in SPFN1.MAC).


            10.   The following User Area Manipulation routines have been 
        added:

        Routine   Module         Function
        -------   ------         --------
        GUA       SGUA.MAC       Get Current User Area in A
        SUA       SSUA.MAC       Set User Area in A

            11.   The following file attribute manipulation routines have 
        been added:

        Routine   Module         Function
        -------   ------         --------
        GFA       SGFA.MAC       Return File Attributes
        SCFA      SSCFA.MAC      Set and Clear File Attributes
        SFA       SFA.MAC        Set File Attributes










                                                           Page 4





                            SYSLIB 3.0 Upgrade Notes



        B.  New SYSLIB Routines and Modules, Con't

            12.   The  following  random file access routines  have  been 
        added:

        Routine   Module         Function
        -------   ------         --------
        R$READ    SRREAD         Random Block Read
        R$WRITE   SRWRITE        Random Block Write



        C.  Documentation

             1.   All  of the SYSLIB.HLP files have been  rewritten,  and 
        many new files have been added.   These files completely document 
        SYSLIB 3.0.  There are 20 SYSLIB 3.0 HLP Files.

             2.   Realizing  the investment some people have in hard copy 
        of the SYSLIB 2.4 documentation,  I do not intend to release  new 
        SYSLIB 3.0 manuals at this time.  This update and the four Z2SYS-
        n.MOD  files  will serve to bring your documentation up to  date.  
        The  SYSLIBx.HLP files should be used as  the  complete,  on-line 
        authoritative reference.


                                                Richard Conn





























                                                           Page 5





 2-Feb-84 11:27:30-MST,1105;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 2 Feb 84 11:27:25-MST
Date:     Thu, 2 Feb 84 12:43:14 EST
From:     Dave Towson (info-cpm) <cpmlist@brl-vgr>
To:       info-cpm@brl-vgr
Subject:  General interest.

I just received a request from Larry Byard to change his address for receiving
this list form byard@dca-ems to byard@obl.  When I sent him a reply saying
that the change had been made, he sent the following message.  I haven't 
studied the list to see who else might be on it from outside of the continental
US, but if we didn't have it already, we now have an international list.

----- Forwarded message # 1:

Received: From Dca-Ems.ARPA by BRL-VGR via smtp;  2 Feb 84 3:32 EST
Date: 2 February 1984 03:12 EST
From: Byard @ DCA-EMS
To: cpmlist @ brl-vgr

Date: February 2, 1984
Re:   Re:  Address for receiving INFO-CPM
Text: Thank you, Dave.  As a matter of possible interest, OBL is located
in Oberursal, West Germany.  Larry


----- End of forwarded messages



Dave Towson
info-cpm-request@brl-vgr


 2-Feb-84 12:30:50-MST,605;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 2 Feb 84 12:30:43-MST
Received: From Simtel20.ARPA by BRL-VGR via smtp;  2 Feb 84 14:04 EST
Date: Thu 2 Feb 84 12:04:23-MST
From: Keith Petersen <KPETERSEN@SIMTEL20.ARPA>
Subject: MODEM program wanted for C64 CP/M
To: Info-Micro@BRL-VGR.ARPA, Info-Cpm@BRL-VGR.ARPA

Does anyone have a Ward Christensen protocol MODEM program that
works with the Commodore 64 CP/M cartridge?  I have several friends
who are trying to figure out how to address a modem port for serial
I/O while in CP/M.
-------
 2-Feb-84 14:12:50-MST,823;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 2 Feb 84 14:12:45-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  2 Feb 84 15:46 EST
Received: From Sumex-Aim.ARPA by BRL via smtp;  2 Feb 84 15:41 EST
Delivery-Notice: While sending this message to BRL.ARPA, the
 SUMEX-AIM.ARPA mailer was obliged to send this message in 50-byte
 individually Pushed segments because normal TCP stream transmission
 timed out.  This probably indicates a problem with the receiving TCP
 or SMTP server.  See your site's software support if you have any questions.
Date: Thu 2 Feb 84 12:32:14-PST
From: Dan Kent <KENT@SUMEX-AIM.ARPA>
Subject: what is ZCPR3 ??
To: info-cpm@BRL.ARPA

I'm a newcomer to this world of CPM-INFO.  Is there a glossary somewhere?
-------
 2-Feb-84 19:23:03-MST,1488;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 2 Feb 84 19:22:56-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  2 Feb 84 20:58 EST
Received: From Sumex-Aim.ARPA by BRL via smtp;  2 Feb 84 20:49 EST
Return-Path: <MAILER-DAEMON@LANL>
Received: from lanl by SUMEX-AIM.ARPA with TCP; Thu 2 Feb 84 13:23:19-PST
Date:  2 Feb 1984 14:15:43 (Thu)
From: MAILER-DAEMON@lanl
Subject: Undeliverable mail
To: KENT@sumex-aim
ReSent-date: Thu 2 Feb 84 17:53:49-PST
ReSent-from: Dan Kent <KENT@SUMEX-AIM.ARPA>
ReSent-to: INFO-CPM@BRL.ARPA

Mail addressed to post-info-cpm at a could not be sent.
421 Mail system botch at LANL-A
------- Unsent message is below -------

Date: 2 Feb 1984 14:05:37-MST
From: KENT@SUMEX-AIM
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  2 Feb 84 15:46 EST
Received: From Sumex-Aim.ARPA by BRL via smtp;  2 Feb 84 15:41 EST
Delivery-Notice: While sending this message to BRL.ARPA, the
 SUMEX-AIM.ARPA mailer was obliged to send this message in 50-byte
 individually Pushed segments because normal TCP stream transmission
 timed out.  This probably indicates a problem with the receiving TCP
 or SMTP server.  See your site's software support if you have any questions.
Date: Thu 2 Feb 84 12:32:14-PST
From: Dan Kent <KENT@SUMEX-AIM.ARPA>
Subject: what is ZCPR3 ??
To: info-cpm@BRL.ARPA

I'm a newcomer to this world of CPM-INFO.  Is there a glossary somewhere?
-------
 3-Feb-84 08:38:48-MST,848;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 3 Feb 84 08:38:42-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  3 Feb 84 3:30 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  3 Feb 84 3:21 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 3 Feb 84 0:08-PST
Date: 31 Jan 84 19:59:01-PST (Tue)
To: info-cpm@brl
From: pur-ee!uiucdcs!ccvaxa!mikel@ucb-vax
Subject: squeeze/unsqueeze - (nf)
Article-I.D.: uiucdcs.5289

#N:ccvaxa:24000001:000:272
ccvaxa!mikel    Jan 17 14:45:00 1984

I need help getting a copy of the squeeze and unsqueeze programs.  I have
uploaded a cpm disk on the vax and want to unsqueeze some of the files.
Does anyone have a copy that i can get?

					Thanks,
					Mikel Matthews
					pur-ee!uiucdcs!ccvaxa!mikel
					mikel@compion
 3-Feb-84 08:39:26-MST,1840;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 3 Feb 84 08:39:17-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  3 Feb 84 3:54 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  3 Feb 84 3:48 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 3 Feb 84 0:40-PST
Date: 31 Jan 84 20:22:23-PST (Tue)
To: info-cpm@brl
From: pur-ee!uiucdcs!parsec!ctvax!uokvax!emjhm@ucb-vax
Subject: CONIX for CP/M - (nf)
Article-I.D.: uiucdcs.5295

#N:uokvax:7900012:000:1244
uokvax!emjhm    Jan 30 17:32:00 1984

Does anyone know anything about the CONIX shell that runs on 32K or greater
CP/m systems.  I saw a full page advertisement in the Feb. "Computer Shopper"
that said it could handle quite a few of the nice things that UNIX has to
offer like file pipes/tees and re-direction to name a few.  It looks pretty
decent for those of us who can't afford full blown UNIX or who are stuck
with mere finite spaced, relatively slow floppy disks systems and 8080 or
Z-80 processors.  Some of the nice things about CONIX seem to be that you
can use only the parts that you want or disable functions or frills that
you don't need or haven't the capacity for.  They also say a few things  
in their ad which seem to be contradictory.  Like for instance they say
that the CONIX command processor will run under any CP/M and BIOS on virtually
any machine without modification and in the same breath say that it can
access 16 disk drives(actual or virtual if they don't exist).  How would
that be possible without at least fiddling with the BIOS jump vectors?
Some folks have their CBIOS in ROM.  Will it run on their system?  I'd
appreciate hearing from anyone that has heard anything or is presently
using CONIX.  There's got to be a gotcha somewhere.
Jim Miller
 3-Feb-84 08:39:35-MST,1271;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 3 Feb 84 08:39:28-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  3 Feb 84 3:54 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  3 Feb 84 3:49 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 3 Feb 84 0:39-PST
Date: 31 Jan 84 20:22:11-PST (Tue)
To: info-cpm@brl
From: pur-ee!uiucdcs!parsec!ctvax!uokvax!emjhm@ucb-vax
Subject: Re: Zenith 100 - (nf)
Article-I.D.: uiucdcs.5294

#R:ut-ngp:-24200:uokvax:7900011:000:670
uokvax!emjhm    Jan 30 17:01:00 1984

The Z-100 does indeed hane an IEE-696 S-100 bus in it.  The 8085 and 8088
processors work in tandem and appear as a single master cpu on the bus.
As for "Standard S-100 single board processors and hard disk controllers"
just play like you have a processor and memory board installed in the S-100
bus that can't be removed.  The S-100 bus wil tolerate slave processors on
the bus but the slave will have to be given the bus by the 8085 or 8088
processors that are always present and must be running to keep the display
going.  I'm not sure how much trouble you would have in trying to get
a single board S-100 processors to play slave to the Z-100 processors.
Jim Miller
 3-Feb-84 08:41:26-MST,2179;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 3 Feb 84 08:41:00-MST
Received: From Csnet-Cic.ARPA by BRL-VGR via smtp;  3 Feb 84 7:18 EST
Date: 3 Feb 1984 01:23:16-EST
From: erh%virginia@csnet-relay
Return-Path: <erh%Virginia@CSNet-Relay>
To: Info-Cpm@brl-vgr
Via:  Virginia; 3 Feb 84 6:16-EST

1
	I have recently obtained MDM716 and I am gratified with its
performance.  I submit the following suggestions in hope of making the
excellent thing better:

1. The overlay method of customizing the program is still too specific.
Ideally, there should be two clearly defined overlays:
	-- an outer one containing all procedures for a given modem
	or modem setup.  There would be one overlay for PMMI, another for
	Hayes, etc.  This overlay should contain well isolated procedures
	to hang up the modem, send a break, etc.  The way it is now, a 
	Hayes user has to wade through all the PMMI stuff to find the 
	relevant code (not mentioning the fact that the code for the 
	other modems just sits there and uses the precious K's).  To wit:
	Hayes can be told to hang up by dropping DTR, which is infinitely
	faster than sending the #$%! pluses, but the DISCONNECT stuff is 
	buried too well for me to bother. That outer overlay should contain 
	procedures to do all kinds of exotic things, such as change the baud 
	rates, etc.  Use flags to indicate which procedures are valid.
	-- an inner one dealing with the i/o hardware: sending and 
	receiving characters from the modem.  And please, have somewhat 
	more general procedures.  The functions to mask a status byte are
	cute, but too primitive.  The guys using interrupts and BIOS 
	bufferring of incoming characters would prefer to use a system
	or BIOS call to get/test for input characters.

2. The dialing procedures could be somewhat smarter.  Use some way of 
separating the decription from the phone number.  The way it is now,
all digits get dialed out, including things like "Gandalf1, 1200bps...".
I also agree with a recent remark about necessity of controlling the
pulse/tone dialing mode.

~v~ Ed Howorka, erh@uvacs
 ~

 3-Feb-84 08:43:22-MST,699;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 3 Feb 84 08:43:18-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  3 Feb 84 9:07 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  3 Feb 84 8:59 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 3 Feb 84 5:55-PST
Date: 1 Feb 84 16:57:32-PST (Wed)
To: info-cpm@brl
From: ihnp4!houxm!mhuxl!aluxp!wrbull@ucb-vax
Subject: Access to SIMTEL
Article-I.D.: aluxp.1179

Can ATT Bell Laboratories access SIMTEL and if yes, how? Any help
is greatly appreciated.

Thanks in Advance...		W.R.Bullman
				(215)439-5550

	Path:(I'm new on the net but...) ...aluxp!wrbull (???)
 3-Feb-84 09:51:16-MST,464;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 3 Feb 84 09:51:12-MST
Date:     Fri, 3 Feb 84 11:29:11 EST
From:     Dave Towson (info-cpm) <cpmlist@brl-vgr>
To:       info-cpm@brl-vgr
Subject:  Burton, where are you?

I had a request to add AMD70!FORTUNE!BURTON@BERKELEY to this list.  The
mailer won't accept that address.  Got another address, Burton?



Dave Towson
info-cpm-request@brl-vgr


 3-Feb-84 10:27:04-MST,682;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 3 Feb 84 10:26:59-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  3 Feb 84 11:54 EST
Received: From Parc-Maxc.ARPA by BRL via smtp;  3 Feb 84 11:43 EST
Date: Fri, 3 Feb 84 08:45 PST
From: MMOON.ES@PARC-MAXC.ARPA
Subject: Re: Public domain for -86
In-reply-to: "DHead's message of Thu, 2 Feb 84 08:23 PST"
To: DHead.ES@PARC-MAXC.ARPA
cc: INFO-CPM@BRL.ARPA


The only CP/M-86 related  PD software I have seen was on Sigi Kluger's
system in El Paso, Texas, but then I do very littlte long-haul searching
or downloading due to 300 baud limits.
			MMoon.es

 3-Feb-84 11:27:36-MST,1035;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 3 Feb 84 11:27:32-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  3 Feb 84 12:55 EST
Received: From Rochester.ARPA by BRL via smtp;  3 Feb 84 12:40 EST
Received: by sen.rochester (3.327.3N) id AA10011; 3 Feb 84 12:41:16 EST (Fri)
Received: by cay.Rochester (3.327.3N+) id AA05568; 3 Feb 84 12:37:57 EST (Fri)
Message-Id: <8402031741.10011@sen.rochester>
Date: 3 Feb 84 12:41:16 EST (Fri)
From: Mike Ciaraldi <ciaraldi@Rochester.ARPA>
Subject: Re:  PD programs  to do file compares...
To: LIN@mit-ml.ARPA, info-cpm@brl.ARPA

There are BDS C programs in the public domain to do file compartisons.
These are avaialble on one of the CPMUG volumes.
The set includes DIF2, which is like the Unix DIFF (it finds the
differences), and SSED, which is a stream editor that
can use the difference files to turn one text into another.
I have used them on CP/M-80, and they work OK.

Mike Ciaraldi
ciaraldi@rochester
 3-Feb-84 11:30:02-MST,1082;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 3 Feb 84 11:29:58-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  3 Feb 84 12:54 EST
Received: From Rochester.ARPA by BRL via smtp;  3 Feb 84 12:38 EST
Received: by sen.rochester (3.327.3N) id AA09926; 3 Feb 84 12:38:48 EST (Fri)
Received: by cay.Rochester (3.327.3N+) id AA05558; 3 Feb 84 12:35:44 EST (Fri)
Message-Id: <8402031738.9926@sen.rochester>
Date: 3 Feb 84 12:38:48 EST (Fri)
From: Mike Ciaraldi <ciaraldi@Rochester.ARPA>
Subject: Floppies on VAX
To: allegra!fortune!burton@Rochester.ARPA, 
    allegra!rochester!ciaraldi@Rochester.ARPA
Cc: info-cpm@brl.ARPA

There is a program called CPMUTL.C on the SIMTEL archives
in MICRO:<UNIX.CPM>.
This is supposed to run on a 780 and let you read and write CP/M
floppies under Unix. I have not tried it,
so I don't know if 1) it works, and 2) it would work on
a 750. But, you might try.

This message is in response to a
question from allegra!fortune!burton.

Mike Ciaraldi
ciaraldi@rochester
 3-Feb-84 14:26:40-MST,1269;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 3 Feb 84 14:26:35-MST
Received: From Usc-Ecl.ARPA by BRL-VGR via smtp;  3 Feb 84 15:50 EST
Date:  3 Feb 1984 1240-PST
From: Ted Shapin <BEC.SHAPIN@USC-ECL.ARPA>
Subject: The problem with LISTST
To: wancho@SIMTEL20.ARPA
cc: info-cpm@BRL-VGR.ARPA
Postal-address: Beckman Instruments, Inc.
Postal-address: 2500 Harbor X-11, Fullerton, CA 92634
Phone: (714)961-3393

Digital Research made an error in their manual in describing what LISTST
should do.

"The value 00 is returned in A if the list device in not ready to accept
a character and 0FFH if a character can be sent to the printer. A 00 [!] value
should be returned if LISTST is not implemented."

An application program cannot know whether the BIOS implemented LISTST or
not.  If the application program uses this BIOS entry point and assumes it
is implemented according to DRI's instructions, it will loop forever waiting
for a 0FFH if tha BIOS doesn't implement LISTST and returns a 00.

I do my checking for printer ready in the LIST code which outputs a character.

It sounds like Lifeboaat may have done a similar thing and perhaps there is
a bug in the LIST routine.
Ted.
-------
 3-Feb-84 19:21:07-MST,471;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 3 Feb 84 19:21:04-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  3 Feb 84 20:53 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  3 Feb 84 20:40 EST
Date: 3 February 1984 20:42 EST
From: Herb Lin <LIN@mit-mc>
Subject:  getting KERMIT - where is it?
To: info-cpm@brl

I remember it is at columbia somewhere, but what are the pathnames etc...

tnx.

 6-Feb-84 08:34:06-MST,712;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 6 Feb 84 08:34:00-MST
Received: From Brl-Bmd.ARPA by BRL-VGR via smtp;  5 Feb 84 9:07 EST
Date:     Sun, 5 Feb 84 8:55:43 EST
From:     Charlie Strom (NYU) <strom@brl-bmd>
To:       INFO-CPM@brl-vgr
Subject:  Standard needed

I have been asked to poll the user community on siuggestions as ti a naming
convention for CP/M-86 object code files. Calling them .CMD (on an RCPM) will
cause confusion with DBASE command files; needless to say if the RCPM is running
CP/M-86, it would be disastrous to have all these .CMD files sitting there as
well. One suggestion is .O86. I would appreciate your input.
 6-Feb-84 08:35:10-MST,980;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 6 Feb 84 08:34:46-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  5 Feb 84 9:56 EST
Date:     Sun, 5 Feb 84 9:44:11 EST
From:     Keith Petersen <w8sdz@brl>
To:       Info-Cpm@brl-vgr
Subject:  Changes to Royal Oak RCPM

The Royal Oak (Michigan) RCPM no longer requires "callback".  It
now answers on your first call and accepts 110, 300, 450, 600 and
710 baud (using 103 tones).

The floppy drives are no longer in service.  The 10 megabyte hard
disk has been replaced with a 26 megabyte hard disk partitioned
into four logical drives.

Info-Cpm readers who do not have access to SIMTEL20 will find many
of the same files are available on the Royal Oak RCPM.

Sometime in the near future a 300/1200 baud modem may be added.
I will announce it on Info-Cpm if/when it happens.

The phone number for the Royal Oak RCPM is (313) 759-6569.

--Keith
 6-Feb-84 08:35:14-MST,605;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 6 Feb 84 08:35:03-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  5 Feb 84 13:29 EST
Received: From Amsaa.ARPA by BRL via smtp;  5 Feb 84 13:20 EST
Date:     Sun, 5 Feb 84 13:15:57 EST
From:     David Towson (CSD) <towson@amsaa>
To:       Herb Lin <LIN@mit-mc>
cc:       info-cpm@brl
Subject:  Re:  getting KERMIT - where is it?

Herb - Kermit is on Columbia-20 in directory PS:<KERMIT>.  Using FTP, do

          "dir ps:<kermit>"

to see what's there.


Dave
towson@amsaa

 6-Feb-84 08:38:28-MST,1374;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 6 Feb 84 08:38:16-MST
Received: From Usc-Eclb.ARPA by BRL-VGR via smtp;  6 Feb 84 0:57 EST
Date: 5 February 1984  21:55-PST (Sunday)
Sender: TLI@usc-eclb
From: Tony Li <Tli@usc-eclb>
To:   Info-Micro@brl-vgr, Info-CPM@brl-vgr
Subject: CP/M 80 programs on a 68K...
Reply-to: Tli@usc-eclb
Home: 1275 W. 29th #211, Los Angeles, Ca. 90007  (213) 737-8168


For all of you who are just dying to run your 68K as a souped up
8080...

EM80 - an 8080 & CP/M-80 emulator for CP/M-68K
Empirical Research Group, Inc.
P.O. Box 1176
Milton WA 98354

From the spec sheet...  

"This emulator requires a minimum of 128K of memory be available.
This does, however, also include the space occupied by CP/M-68K
itself....

All normal BDOS calls are supported by the software emulation.  All
direct BIOS calls, except for the disk related ones, are also
correctly handled by EM80...

At present, only 8080 opcodes are supported by the emulator.  A future
release will support all Z80 opcodes..."

Example of usage:

A> EM80 PIP A:=B:TEST.DAT[V]

Cheers,
Tony ;-)

P.S.  Before you go running this on you Mac, though, you first have to
get CP/M-68K up and running.  If anyone has or is working on a BIOS
for the Mac, how about dropping the list a line?
 6-Feb-84 08:40:13-MST,811;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 6 Feb 84 08:39:34-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  4 Feb 84 5:53 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  4 Feb 84 5:47 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 4 Feb 84 2:39-PST
Date: 25 Jan 84 9:19:30-PST (Wed)
To: info-cpm@brl
From: harpo!seismo!rlgvax!plunkett@ucb-vax
Subject: Gordon "CBASIC" Eubanks
Article-I.D.: rlgvax.1615

Gordon Eubanks, Jr., a true pioneer in the microcomputer field with
his E-BASIC, CBASIC, and later CB-80, etc., is listed in the SOFTCON
notice as no longer at Digital Research, Inc.  Now a so-called
"Independent Consultant".  Does anyone know anything more about
this?

..{allegra|seismo}!rlgvax!plunkett
 6-Feb-84 08:42:10-MST,549;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 6 Feb 84 08:42:03-MST
Received: From Rand-Relay.ARPA by BRL-VGR via smtp;  4 Feb 84 18:42 EST
Date: 4 Feb 1984 09:36:40-EST
From: goldfarb.ucf-cs@rand-relay
Return-Path: <goldfarb.UCF-CS@Rand-Relay>
Subject: squeeze/unsqueeze for Unix
To: info-cpm@brl-vgr, purdue!pur-ee!uiucdcs!ccvaxa!mikel.ucf-cs@rand-relay
Via:  UCF-CS; 4 Feb 84 15:30-PST

I am sending them to you via Unix mail.
					Ben Goldfarb
					{duke,decvax}!ucf-cs!goldfarb
 6-Feb-84 08:43:14-MST,841;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 6 Feb 84 08:43:03-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  5 Feb 84 1:14 EST
Received: From Usc-Isid.ARPA by BRL via smtp;  5 Feb 84 1:03 EST
Date: 4 Feb 1984 09:53-PST
Sender: ABN.ISCAMS@usc-isid
Subject: Re:  getting KERMIT - where is it?
From: ABN.ISCAMS@usc-isid
To: LIN@mit-mc
Cc: info-cpm@brl
Message-ID: <[USC-ISID] 4-Feb-84 09:53:11.ABN.ISCAMS>
In-Reply-To: The message of 3 February 1984 20:42 EST from Herb Lin <LIN@mit-mc>

Herb,

KERMIT is at (via FTP)
COLUMBIA20  (can't remember if the 20 should be -20; try both)
DIR <KERMIT>  will get you the listing
GET <KERMIT>-README.TXT (I think that's the title) will get you the latest
update on goings on.

Regards,
David Kirschbaum
Toad Hall
 6-Feb-84 11:10:11-MST,937;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 6 Feb 84 11:09:59-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  6 Feb 84 12:28 EST
Received: From Mit-Multics.ARPA by BRL via smtp;  6 Feb 84 12:09 EST
Date:  Mon, 6 Feb 84 12:04 EST
From:  Woodie@MIT-MULTICS.ARPA
Subject:  SID/ZSID
To:  info-cpm@BRL.ARPA
Message-ID:  <840206170454.575774@MIT-MULTICS.ARPA>

          When I try to use the "assemble" mode of SID to assemble code
directly into memory, I find that any references to memory addresses in
BIOS are rejected.  I can assemble code which references the "Transient
Program Area" (e.g., STA 105h) but not that same code if it references
BIOS (maybe BDOS as well), e.g., STA EF00 (Which is in my Osborne 1's
BIOS).  Can anyone tell me if this "feature" was put there on purpose,
or how to get around it?

Paul Woodie (Woodie.DODCSC at MIT-MULTICS)
 6-Feb-84 11:10:44-MST,1004;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 6 Feb 84 11:10:32-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  6 Feb 84 12:47 EST
Received: From Mit-Multics.ARPA by BRL via smtp;  6 Feb 84 12:34 EST
Posted-Date:  6 Feb 84 12:23 EST
Date:  Mon, 6 Feb 84 12:22 EST
From:  Woodie@MIT-MULTICS.ARPA
Subject:  ddd.asm
To:  info-cpm@BRL.ARPA
Message-ID:  <840206172242.019832@MIT-MULTICS.ARPA>

          Has any one used the ddd.asm program ( which is in the
simtel20 collection) on the Osborne 1?  (That is, or is supposed to be,
the program that should allow disk head alignment with out the use of a
dual-trace oscilloscope).  I know that the 8080 assembly language
program was meant to be customized to the particular host machine, and I
have done some of that for my Osborne 1, but I would like to communicate
with anyone who has completed that process and used to program.


Paul Woodie (Woodie.DODCSC at mit-multics)
 7-Feb-84 08:20:17-MST,925;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 7 Feb 84 08:20:10-MST
Received: From Rand-Relay.ARPA by BRL-VGR via smtp;  7 Feb 84 0:57 EST
Date: 6 Feb 1984 09:33:40-EST
From: goldfarb.ucf-cs@rand-relay
Return-Path: <goldfarb.UCF-CS@Rand-Relay>
Subject: Re:  Changes to Royal Oak RCPM
To: w8sdz@brl
Cc: info-cpm@brl-vgr
Via:  UCF-CS; 6 Feb 84 19:46-PST

congratulations, Keith!  Sounds like you're moving ahead nicely.  One 
question.  Sigi Kluger seems to be leading the pack toward charging
set fees for "membership" in RCP/M's around the country.  One system
here has decided to go that way, stating that "the best systems" around the 
country are doing it.  I really have no objection to his doing whatever
he wants with his system, but I am interested in what the "Father of
RCP/M" has to say on the subject in general.  Can you comment?

				Ben 
 7-Feb-84 08:20:27-MST,665;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 7 Feb 84 08:20:20-MST
Received: From Csnet-Cic.ARPA by BRL-VGR via smtp;  7 Feb 84 1:38 EST
Date: 6 Feb 1984 10:39:17-EST
From: erh%virginia@csnet-relay
Return-Path: <erh%Virginia@CSNet-Relay>
Subject: Standard needed
To: INFO-CPM@brl-vgr, mmdf%virginia@csnet-relay
Via:  Virginia; 7 Feb 84 0:17-EST

About the naming of RCPM CP/M86 files: how about ".B86" (for Binary
or oBject), or "86J" (this would allow looking at all object files
using "DIR *.??J").  I am against ".O86", since it is easy to confuse
with ".086".
~v~ Ed Howorka, erh@uvacs
 ~

 7-Feb-84 08:22:31-MST,2667;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 7 Feb 84 08:22:14-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  7 Feb 84 4:10 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  7 Feb 84 4:04 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 7 Feb 84 0:56-PST
Date: 1 Feb 84 13:25:38-PST (Wed)
To: info-cpm@brl
From: ihnp4!alberta!ubc-vision!uw-beaver!ssc-vax!fluke!ipspec@ucb-vax
Subject: List of Kaypro ports and baud codes
Article-I.D.: vax1.489

This is the complete list (I think) of port addresses for the Kaypro 2, and
older 4's.  The newer 4's will use some of the unused ports for the new added
standard features such as the real time clock and modem (hope you have heard 
about that).  The 10 I think falls same way, basically same as below but some 
of extras like the light use some of the 'unused' ports.

Ports are selected in groups of 4 by U57, then individually by A0 and A1 of the
address bus. (Baud rates ports dont't bother with the individule select.)

0      RS-232 serial baud rate, W (write only)              BAUD RATE CODES
1-3    Unused (actually will perform same as port 0)           0       50
4      RS-232 serial data, R/W  (read/write)                   1       75
5      Keyboard serial data, R/W                               2      110
6      RS-232 status, R/W                                      3      134.5
7      Keyboard status, R/W                                    4      150
8      Parallel printer data, R/W                              5      300
9      Unused PIO (port B of U54), R/W                         6      600 
A      Parallel printer status, R/W                            7     1200
B      Status for unused port 9, R/W                           8     1800
C      Keyboard baud rate, W.  (but don't change it)           9     2000
D-F    Unused (actually will perform same as port C)           A     2400
10-13  Disk I/O functions, R/W                                 B     3600
14-17  Unconnected. Pin 10 of U57 decodes this block of 4      C     4800
18-1B  Unconnected. Pin 9  of U57 decodes this block of 4      D     7200
1C     System port, R/W. (disk select, motor control,          E     9600
                                 & printer handshakes)         F   19,200
1D     Unused PIO (port B of U72), R/W
1E     Status of port 1C, R/W
1F     Status of unused port 1D, R/W

This is actually my first pass this and hasn't all been verified.  If someone 
would add in the info the new 4's and 10's and repost it, I'm sure that all 
interested would thankful.

Regards,
Al Weiss 
 7-Feb-84 08:24:07-MST,485;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 7 Feb 84 08:23:56-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  7 Feb 84 6:17 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  7 Feb 84 6:12 EST
Date: 7 February 1984 06:14 EST
From: Jerry E. Pournelle <POURNE@mit-mc>
Subject: BYTE arrived...
To: INFO-CPM@mit-mc

Saturday 4 February in Hollywood (second class; I've had the Fed
Expressed copy for some time.)

 7-Feb-84 08:35:33-MST,683;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 7 Feb 84 08:35:29-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  7 Feb 84 8:20 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  7 Feb 84 7:52 EST
Date:  7 Feb 1984 0450-PST
From: Crede Edens <Edens@office-3>
Subject: MODEMS WANTED
To:   INFO-CPM@mit-mc
cc:   EDENS@BRL.ARPA


Some time last year I saw a message that someone posted concerning some
U.S. Robotics modems for sale for a very reasonable price.  Are there some of
these still available?  Or does someone know of another brand for sale
reasonable?

Reply to EDENS@OFFICE-3

THANKS
-------

 7-Feb-84 08:48:58-MST,1037;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 7 Feb 84 08:48:52-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  7 Feb 84 9:59 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  7 Feb 84 9:51 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 7 Feb 84 6:38-PST
Date: 6 Feb 84 16:09:43-PST (Mon)
To: info-cpm@brl
From: hplabs!zehntel!dual!fortune!burton@ucb-vax
Subject: Re: Siemens Floppy Drives - Parts & Serv - (nf)
Article-I.D.: fortune.2452

#R:linus:-64200:fortune:25500005:000:414
fortune!burton    Feb  6 12:12:00 1984


Since this is a public net, and the libel laws apply, I won't say more
about Siemens, and believe me, I don't believe in paying retail [I was
born and raised in NYC], but it's not worth it for Siemens.

  Philip Burton      101 Twin Dolphin Drive
  Fortune Systems    Redwood City, CA  94065	   (415) 595-8444 x 526
			- - -
{allegra,[decvax!decwrl,ucbvax]!amd70,cbosgd,harpo,hpda,ihnp4,sri-unix}
!fortune!burton
 7-Feb-84 11:31:39-MST,11370;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 7 Feb 84 11:31:14-MST
Date:     Tue, 7 Feb 84 12:36:02 EST
From:     Dave Towson (info-cpm) <cpmlist@brl-vgr>
To:       info-cpm@brl-vgr
Subject:  [phil%euler:  Sorry...]
          [phil%euler:  MODEM7 for the C64]


----- Forwarded message # 1:

Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  6 Feb 84 18:37 EST
Received: From Ucb-Vax.ARPA by BRL via smtp;  6 Feb 84 18:29 EST
Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.22/4.21)
	id AA02030; Mon, 6 Feb 84 15:22:34 pst
Received: from ucbruby.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA
	(4.13/4.13) id AA11835; Mon, 6 Feb 84 15:29:37 pst
Received: by ucbruby.CC.Berkeley.ARPA
	(4.13/4.13) id AA10364; Mon, 6 Feb 84 14:51:29 pst
Date: Mon, 6 Feb 84 14:51:29 pst
From: phil%euler@BRL.ARPA
Message-Id: <8402062251.AA10364@ucbruby.CC.Berkeley.ARPA>
To: ruby.info-cpm-request@brl
Subject: Sorry...

     It seems I may have sent a rather lengthy file to info-cpm-request
instead of to info-cpm as was intended; if you could send it out to
info-cpm I would appreciate it.

     If I didn't screw up, then disregard this notice.

					Phil

				(jlapsley%D.CC@Berkeley, NOT %ucbeuler)

----- Forwarded message # 2:

Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  6 Feb 84 18:38 EST
Received: From Ucb-Vax.ARPA by BRL via smtp;  6 Feb 84 18:30 EST
Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.22/4.21)
	id AA02059; Mon, 6 Feb 84 15:23:32 pst
Received: from ucbruby.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA
	(4.13/4.13) id AA11846; Mon, 6 Feb 84 15:30:39 pst
Received: by ucbruby.CC.Berkeley.ARPA
	(4.13/4.13) id AA10208; Mon, 6 Feb 84 14:37:58 pst
Date: Mon, 6 Feb 84 14:37:58 pst
From: phil%euler@BRL.ARPA
Message-Id: <8402062237.AA10208@ucbruby.CC.Berkeley.ARPA>
To: ruby.info-cpm-request@brl
Subject: MODEM7 for the C64

     I recall someone recently asking about the availability of modem7
or xmodem programs for the C64 under CP/M.  As it happened, fairly
randomly, someone just sent me this -- I have not used it and I know
nothing about it (I don't even have a C64), but I thought I might
send it to the net.

					Phil
			(contrary to the "From" field, I am still
			at "jlapsley%D.CC@Berkeley")

------------

Date: Mon, 6 Feb 84 12:44:55 pst
From: jmrubin@ucbcoral (Joel Rubin)
To: jlapsley@D
Subject: xmodem for C'64

	I don't know if you're still looking for
an xmodem protocol program for the C'64, but here is one.
I haven't tried it yet.  (Documentation+Hexfile)


MODEM64: DOCUMENTATION
BY CHRIS LAMPTON, 75275,1373
01/29/84


    MODEM64 IS A SIMPLE TERMINAL
EMULATOR WITH XMODEM DOWNLOAD FACILI-
TIES, DESIGNED TO RUN UNDER COMMODORE
64 CP/M. IT WILL NOT RUN UNDER OTHER
VERSIONS OF CP/M; IN FACT, IT WILL ONLY
RUN UNDER THE CP/M PACKAGE OFFERED BY
COMMODORE BUSINESS MACHINES.
    WHEN FIRST RUN, MODEM64 IS IN
NORMAL TERMINAL MODE. ASCII DATA RE-
CEIVED THROUGH THE RS-232 PORT IS DIS-
PLAYED ON THE SCREEN. DATA TYPED ON THE
KEYBOARD IS TRANSMITTED. PARITY IS
IGNORED. MOST STANDARD ASCII CONTROL
CODES ARE IMPLEMENTED. TO EXIT MODEM64
PRESS FUNCTION KEY F2 (SHIFT-F1).
XMODEM DOWNLOADS ARE INITIATED BY
PRESSING FUNCTION KEY F8 (SHIFT-F7).


USING MODEM64 WITH AN RCP/M
(REMOTE CP/M DATABASE)


    THE STANDARD RCP/M COMMAND FOR
XMODEM TRANSMISSION IS:

XMODEM S FILENAME.EXT

    IF THE SPECIFIED FILE IS AVAILABLE,
THE RCP/M WILL RESPOND WITH THE NUMBER
OF 128 BYTE BLOCKS IN THE FILE AND THE
APPROXIMATE DOWNLOAD TIME. IF YOU
SHOULD DECIDE AT THIS POINT THAT YOU
WISH TO ABORT THE DOWNLOAD, PRESS
CTRL-'X' TO SEND AN ASCII CANCEL
SIGNAL TO THE SENDING COMPUTER.
TO BEGIN THE DOWNLOAD, PRESS F8,
AND MODEM64 WILL AUTOMATICALLY
REQUEST THE RCP/M TO START TRANS-
MITTING. THE MESSAGE 'XMODEM TRANSMIS-
SION INITIATED' WILL APPEAR ON THE
SCREEN. IF FOR ANY REASON THE TRANS-
MISSION IS NOT RECEIVED, MODEM64 WILL
CONTINUE BROADCASTING THE REQUEST FOR
APPROXIMATELY 100 SECONDS BEFORE
ABORTING THE DOWNLOAD AND RETURNING TO
TERMINAL MODE. SHOULD THIS OCCUR, THE
MESSAGE 'BLOCK NOT RECEIVED, XMODEM
TRANSMISSION ABORTED' WILL BE DIS-
PLAYED. THE DOWNLOAD MAY BE MANUALLY
ABORTED BY PRESSING THE RUN-STOP KEY.
    ONCE TRANSMISSION HAS BEGUN, THE
DOWNLOADED BLOCKS WILL BE AUTOMATICALLY
SAVED TO THE DISK IN CP/M FORMAT. AS
EACH BLOCK IS RECEIVED, THE MESSAGE
'BLOCK #NN RECEIVED' WILL BE DISPLAYED,
WHERE NN IS THE BLOCK NUMBER IN HEXA-
DECIMAL. IF MORE THAN 255 (FF HEX)
BLOCKS ARE TRANSMITTED, THE BLOCK
NUMBER WILL ROLL OVER TO 00. CHECKSUMS
ARE USED TO VERIFY THE ACCURACY OF THE
TRANSMITTED DATA. AT THE END OF TRANS-
MISSION, MODEM64 WILL INFORM THE
SENDING COMPUTER OF THE SUCCESSFUL
RECEIPT OF THE FILE AND WILL DISPLAY
THE MESSAGE 'XMODEM TRANSMISSION COM-
PLETED' BEFORE RETURNING TO TERMINAL
MODE.
    FILES WILL BE SAVED TO THE DISK
UNDER THE FILENAME 'NEWFILE,' WITH THE
EXTENSION '.XMD'. FILES DOWNLOADED
DURING A SINGLE SESSION WILL BE SEQUEN-
TIALLY NUMBERED, WITH THE FIRST FILE
GIVEN THE NAME 'NEWFILE1.XMD,' THE
SECOND FILE THE NAME 'NEWFILE2.XMD,'
AND SO FORTH. LETTERS OF THE ALPHABET
WILL BE USED ONCE THE TEN NUMERALS ARE
EXHAUSTED. GIVEN THE OBVIOUS LIMITATION
ON FILE NAMES, IT IS RECOMMENDED THAT
YOU NOT DOWNLOAD MORE THAN 35 FILES IN
ONE SESSION, OR YOU MAY FIND UNTYPABLE
ASCII CHARACTERS IN THE NAMES.
    IT IS ALSO RECOMMENDED THAT YOU
RENAME ALL DOWNLOADED FILES IMMEDIATELY
AFTER THE SESSION, USING THE CP/M REN
COMMAND, BECAUSE EXISTING NEWFILES ON
THE DISK WILL BE DELETED BY MODEM64
DURING LATER SESSIONS TO MAKE ROOM FOR
FRESHLY DOWNLOADED FILES WITH THE SAME
SEQUENCE NUMBERS.
    IN THE EVENT THAT YOU ATTEMPT TO
DOWNLOAD TO A FULL DISK (OR A FULL DISK
DIRECTORY), AN ERROR MESSAGE WILL BE
PRINTED AND THE DOWNLOAD ABORTED. ANY
DATA DOWNLOADED TO THE CURRENT FILE
BEFORE THE DISK LIMIT WAS REACHED WILL
BE PRESERVED.
    THIS IMPLEMENTATION OF XMODEM IS
NOT BULLET PROOF. IT IS POSSIBLE FOR
THE SENDING COMPUTER AND THE RECEIVING
COMPUTER TO FALL OUT OF SYNC AND NOT
RECOVER, THOUGH THIS IS NOT A VERY
LIKELY EVENT. SHOULD IT OCCUR, THE
DOWNLOAD WILL MORE THAN LIKELY ABORT
BY ITSELF. HOWEVER, SHOULD YOU NOTICE
AN UNUSUALLY LONG PAUSE BETWEEN BLOCKS
-- SAY 20 SECONDS OR MORE -- YOU SHOULD
ABORT MANUALLY WITH THE RUN-STOP KEY.
THE SENDING COMPUTER MAY CONTINUE
BROADCASTING DATA, BUT WILL NOTICE
WITHIN A FEW SECONDS THAT NO ACKNOW-
LEDGING SIGNAL IS BEING RECEIVED AND
WILL CANCEL THE DOWNLOAD. YOU MAY THEN
INITIATE THE DOWNLOAD AGAIN. THIS HAS
HAPPENED TO ME ONCE IN ROUGHLY 40
DOWNLOADS. SECURITY WILL BE TIGHTENED
IN SUBSEQUENT VERSIONS.
    SUGGESTIONS FOR FUTURE IMPROVEMENTS
AND REPORTS OF CURRENT BUGS SHOULD
BE CONVEYED TO THE AUTHOR VIA COMPU-
SERVE INFORMATION SERVICE EMAIL OR THE
CIS COMMODORE-64 SIG.
:10010000010B0021D601115D00EDB03E093200F96E
:100110002103122206F93E013200CE003A00F95FB7
:100120001600213901195E2356EBCD38013E093204
:1001300000F9210012C31301E9410180018E0197EA
:10014000013A64003CFE3AC24C013E413264003E3A
:1001500000327C00326800326900326A000E0F11F2
:100160005C00CD0500FEFFCA72010E13115C00CDCC
:1001700005000E16115C00CD0500FEFFCA9B01C9EB
:100180000E15115C00CD0500FEFFCAA601C90E10B8
:10019000115C00CD0500C9E1C3000011B4010E09D6
:1001A000CD0500C3AE0111CA010E09CD05003E0107
:1001B000320EF0C94449534B204449524543544FF1
:1001C00052592046554C4C0D0A244449534B204665
:1001D000554C4C0D0A244E455746494C4530584D18
:1001E00044000000000000000000000000000000CB
:1001F00000000000000000000000000000000000FF
:100200004CBC1358AD8602851320F512A99320AB80
:1002100012A200A0031820F0FFA27FA0142029142E
:10022000A201A00C1820F0FFA2A2A014202914A261
:1002300002A0051820F0FFA2B3A014202914A205E3
:10024000A0001820F0FF20F51220CD1220E312A903
:100250000E20AB12207612208F12C98090F62064F7
:10026000124C5412297F0AA8B9D9168504C8B9D9E5
:100270001685056C0400A20520C6FF20E4FFC90016
:10028000F00C297FA8B9591620AB124C7B1260A242
:100290000620C6FFA00084CC20E4FFC900F00BA814
:1002A000B95915C980B00320BE1260A2074820C901
:1002B000FF2072146820D2FFA5138D860260A2056C
:1002C0004820C9FF68A8B9591520D2FF60A905A226
:1002D00002A00320BAFFA904A255A01520BDFF204B
:1002E000C0FF60A906A200A0FF20BAFFA90020BDA0
:1002F000FF20C0FF60A907A203A0FF20BAFFA9004A
:1003000020BDFF20C0FF60A2D3A01420291420A389
:1003100013A915850AA20520C6FFA9808504A91086
:100320008505A901850BA90A8506A50A20BE12A983
:10033000FF85078508A903851220E4FF850DA59197
:100340002980D0034CDA13A50DC900F00BC901F0C8
:100350001AC904D0034CEA13C607D0DDC608D0D9A9
:10036000C612D0D5C606D0C24CD313A906850A2022
:100370004514205F148509204514205F14A9808549
:100380000CA000204514205F149104C8C60CD0F3C3
:10039000204514C50BF0034C111320AD1320FA13A4
:1003A0004C1513A9004CAF13A9044CAF13A9028D2F
:1003B0000009A900850E20E7FF4C000A686820CDDF
:1003C0001220F51220E312A50EC900F00568684C52
:1003D000DA1360A2F3A014202914A207A015202983
:1003E00014A91820BE1220A81360A90620BE12A2CC
:1003F00024A01520291420A81360A242A0152029AA
:1004000014A5094A4A4A4A186930C93A900318693A
:100410000720AB12A509290F186930C93A900318B3
:10042000690720AB12A24AA01586108411A20720EA
:10043000C9FF207214A000B110C900F00720D2FF3C
:10044000C84C37146020E4FF850D20B7FF2908D081
:10045000F4A5912980D00568684CDA13A50D6018C1
:10046000650B850BA50D602072146868A9068D00C8
:100470000960A00184CCA4D3B1D1297F91D1602A95
:100480002A2A20584D4F44454D20363420425920C9
:100490004348524953204C414D50544F4E202A2A34
:1004A0002A004A414E554152592032392C203139C7
:1004B0003834004E4F5420464F5220434F4D4D4547
:1004C000524349414C20444953545249425554499E
:1004D0004F4E000D584D4F44454D205452414E5300
:1004E0004D495353494F4E20494E49544941544573
:1004F000440D00424C4F434B204E4F542052454335
:1005000045495645440D00584D4F44454D205452E1
:10051000414E534D495353494F4E2041424F52543F
:1005200045440D00584D4F44454D205452414E53C3
:100530004D495353494F4E20434F4D504C45544520
:100540000D00424C4F434B20230020524543454968
:100550005645440D00060000000001020304050694
:100560000708090A0B0C0D0E0F100A1213081516B6
:100570001718191A1B1C0C1E1F20212223242526A4
:100580002728292A2B2C2D2E2F3031323334353683
:100590003738393A3B3C3D3E3F40616263646566B3
:1005A0006768696A6B6C6D6E6F7071727374757663
:1005B0007778797A5B5C5D5E5F6041424344454693
:1005C0004748494A4B4C4D4E4F5051525354555643
:1005D0005758595A7B7C7D7E7F0000000000000048
:1005E000000081000080000000000000000000000A
:1005F00000000000000000000000000000000000FB
:1006000000000000000000000000000000000000EA
:1006100000000000000000000000000000000000DA
:1006200000000000000000000000000000000000CA
:1006300000000000000000000000000000000000BA
:1006400000000000000000000000000000000000AA
:100650000000000000000000000001020304050685
:100660000714090A0B930D0E0F100A121308151622
:100670001718191A1B1C0C1E1F20212223242526A3
:100680002728292A2B2C2D2E2F3031323334353682
:100690003738393A3B3C3D3E3F40616263646566B2
:1006A0006768696A6B6C6D6E6F7071727374757662
:1006B0007778797A5B5C5D5E5F6041424344454692
:1006C0004748494A4B4C4D4E4F5051525354555642
:1006D0005758595A7B7C7D7E7F07136714FD02FFB4
:1006E00002FD02FD02FF02FD02FD02FD02FD82F994
:1006F00002FF02FD02FD02F902FF02F90B8B82FFED
:0000000000

----- End of forwarded messages
 7-Feb-84 12:13:02-MST,515;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 7 Feb 84 12:12:59-MST
Received: From Nosc-Cc.ARPA by BRL-VGR via smtp;  7 Feb 84 12:53 EST
Received: by Nosc.ARPA (4.12/4.7)
	id AA03585; Tue, 7 Feb 84 09:53:22 pst
Date: Tue, 7 Feb 84 09:53:22 pst
From: James F. Jperry <jperry@nosc>
Message-Id: <8402071753.AA03585@Nosc.ARPA>
To: info-cpm%brl=vgr@nosc
Cc: jperry@nosc
Subject: release

-------
please remove my name kfrom the info cpm list
-------

 9-Feb-84 18:16:33-MST,796;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Thu 9 Feb 84 18:16:27-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  7 Feb 84 14:55 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  7 Feb 84 14:34 EST
Date: 7 Feb 84 09:49:57 PST (Tuesday)
From: Veizades.PA@PARC-MAXC.ARPA
Subject: CRC error checking in XModem
To: INFO-MODEM7@mit-mc.ARPA, INFO-CPM@mit-mc.ARPA
cc: Veizades.PA@PARC-MAXC.ARPA

I am implementing the XModem protocol on a non CP/M system and I am interested in
the exact method by which the CRC value is generated, what portion of the XModem
packet is used to compute the CRC and the differences in the protocol when the CRC
option is used.  Can anyone out there help?

John Veizades  -  Veizades@PARC-MAXC

 9-Feb-84 18:16:39-MST,1249;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Thu 9 Feb 84 18:16:34-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  7 Feb 84 16:50 EST
Received: From Mit-Multics.ARPA by BRL via smtp;  7 Feb 84 16:34 EST
Received: from CISL-SERVICE-MULTICS.ARPA by MIT-MULTICS.ARPA TCP; 07-Feb-1984 16:16:01-est
Received: from HIS-PHOENIX-MULTICS.ARPA by CISL-SERVICE-MULTICS.ARPA dial; 07-Feb-1984 16:13:01-est
Date:  Tue, 7 Feb 84 14:09 MST
From:  Brzozowski%his-phoenix-multics.arpa@BRL.ARPA
Subject:  Turbo Pascal
To:  info-cpm@BRL.ARPA
Message-ID:  <840207210928.530621@HIS-PHOENIX-MULTICS.ARPA>

   Does anyone out there in netland have a copy of the "Turbo Pascal"
by Borland International as advertized in BYTE?  For the price, it
seems like a good deal to learn Pascal ($49.95), but if it's not
standard it 'aint much of a lesson (Except how NOT to buy a compiler).
Is Boralnd International a reputable company to deal with?
Forgive me if I seem skeptical, but I am wary about great claims and
small prices...

   Any information would be helpful (Diskette formats for CPM-80,
8087 support, etc.).

                    Thanks in advance!
                    Gary Brz...

 9-Feb-84 18:17:00-MST,730;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Thu 9 Feb 84 18:16:56-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  7 Feb 84 18:50 EST
Received: From Cmu-Cs-A.ARPA by BRL via smtp;  7 Feb 84 18:39 EST
Date:  7 Feb 84 1739 EST (Tuesday)
From: George.Wood@cmu-cs-a
To: info-cpm@brl, info-micro@brl
Subject: forth for trs-80/100 wanted
Message-Id: <07Feb84.173934.GW90@CMU-CS-A>

A visitor from Holland would like to get forth for
his trs-80 model 100. He's heard there's one available, 
but is having trouble finding a source/vendor, and
will only be in the U.S. for a week. I'd appreciate 
assistance in helping him find it. 
			George.Wood@CMU-CS-A.ARPA
 9-Feb-84 18:19:14-MST,655;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Thu 9 Feb 84 18:19:08-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  7 Feb 84 20:07 EST
Received: From Parc-Maxc.ARPA by BRL via smtp;  7 Feb 84 20:00 EST
Date: Tue, 7 Feb 84 17:00 PST
From: SSalzman.ES@PARC-MAXC.ARPA
Subject: Re: Turbo Pascal
In-reply-to: <840207210928.530621@HIS-PHOENIX-MULTICS.ARPA>
To: Brzozowski%his-phoenix-multics.arpa@BRL.ARPA
cc: info-cpm@BRL.ARPA

Read Microsystems magazine, Feb issue. They have a review of Turbo
Pascal. According to them it's quite a nice system. I'd look into it.

				Isaac Salzman.
 9-Feb-84 18:30:29-MST,8475;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Thu 9 Feb 84 18:30:10-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  7 Feb 84 20:20 EST
Date:     Tue, 7 Feb 84 20:05:04 EST
From:     Keith Petersen <w8sdz@brl>
To:       Info-Cpm@brl-vgr, Info-Micro@brl-vgr
Subject:  Definition of CP/M MODEM protocol

I guess it's time to re-send this file to the mailing list.  I've
recently received numerous requests for the exact definition of
the Ward Christensen MODEM protocol.  The original uses CHECKSUM
error checking.  MODEM7 introduced CRC error checking but as far
as I know, no one has ever issued a DOC file explaing how that
works.  The source code is well commented and should serve as a
guide.

---from the author of MODEM, Ward Christensen---
MODEM PROTOCOL OVERVIEW  178 lines, 7.5K

1/1/82 by Ward Christensen.  I will maintain a master copy of
this.  Please pass on changes or suggestions via CBBS/Chicago
at (312) 545-8086, or by voice at (312) 849-6279.

NOTE this does not include things which I am not familiar with,
such as the CRC option implemented by John Mahr.

Last Rev: (none)

At the request of Rick Mallinak on behalf of the guys at
Standard Oil with IBM P.C.s, as well as several previous
requests, I finally decided to put my modem protocol into
writing.  It had been previously formally published only in the
AMRAD newsletter.

	Table of Contents
1. DEFINITIONS
2. TRANSMISSION MEDIUM LEVEL PROTOCOL
3. MESSAGE BLOCK LEVEL PROTOCOL
4. FILE LEVEL PROTOCOL
5. DATA FLOW EXAMPLE INCLUDING ERROR RECOVERY
6. PROGRAMMING TIPS.

-------- 1. DEFINITIONS.
<soh>	01H
<eot>	04H
<ack>	06H
<nak>	15H
<can>   18H

-------- 2. TRANSMISSION MEDIUM LEVEL PROTOCOL
Asynchronous, 8 data bits, no parity, one stop bit.

    The protocol imposes no restrictions on the contents of the
data being transmitted.  No control characters are looked for
in the 128-byte data messages.  Absolutely any kind of data may
be sent - binary, ASCII, etc.  The protocol has not formally
been adopted to a 7-bit environment for the transmission of
ASCII-only (or unpacked-hex) data , although it could be simply
by having both ends agree to AND the protocol-dependent data
with 7F hex before validating it.  I specifically am referring
to the checksum, and the block numbers and their ones-
complement.
    Those wishing to maintain compatibility of the CP/M file
structure, i.e. to allow modemming ASCII files to or from CP/M
systems should follow this data format:
  * ASCII tabs used (09H); tabs set every 8.
  * Lines terminated by CR/LF (0DH 0AH)
  * End-of-file indicated by ^Z, 1AH.  (one or more)
  * Data is variable length, i.e. should be considered a
    continuous stream of data bytes, broken into 128-byte
    chunks purely for the purpose of transmission. 
  * A CP/M "peculiarity": If the data ends exactly on a
    128-byte boundary, i.e. CR in 127, and LF in 128, a
    subsequent sector containing the ^Z EOF character(s)
    is optional, but is preferred.  Some utilities or
    user programs still do not handle EOF without ^Zs.
  * The last block sent is no different from others, i.e.
    there is no "short block".  

-------- 3. MESSAGE BLOCK LEVEL PROTOCOL
 Each block of the transfer looks like:
<SOH><blk #><255-blk #><--128 data bytes--><cksum>
    in which:
<SOH>       = 01 hex
<blk #>     = binary number, starts at 01 increments by 1, and
              wraps 0FFH to 00H (not to 01)
<255-blk #> = blk # after going thru 8080 "CMA" instr, i.e.
              each bit complemented in the 8-bit block number.
              Formally, this is the "ones complement".
<cksum>     = the sum of the data bytes only.  Toss any carry.

-------- 4. FILE LEVEL PROTOCOL

---- 4A. COMMON TO BOTH SENDER AND RECEIVER:

    All errors are retried 10 times.  For versions running with
an operator (i.e. NOT with XMODEM), a message is typed after 10
errors asking the operator whether to "retry or quit".
    Some versions of the protocol use <can>, ASCII ^X, to
cancel transmission.  This was never adopted as a standard, as
having a single "abort" character makes the transmission
susceptible to false termination due to an <ack> <nak> or <soh>
being corrupted into a <can> and canceling transmission.
    The protocol may be considered "receiver driven", that is,
the sender need not automatically re-transmit, although it does
in the current implementations.

---- 4B. RECEIVE PROGRAM CONSIDERATIONS:
    The receiver has a 10-second timeout.  It sends a <nak>
every time it times out.  The receiver's first timeout, which
sends a <nak>, signals the transmitter to start.  Optionally,
the receiver could send a <nak> immediately, in case the sender
was ready.  This would save the initial 10 second timeout. 
However, the receiver MUST continue to timeout every 10 seconds
in case the sender wasn't ready.
    Once into a receiving a block, the receiver goes into a
one-second timeout for each character and the checksum.  If the
receiver wishes to <nak> a block for any reason (invalid
header, timeout receiving data), it must wait for the line to
clear.  See "programming tips" for ideas
    Synchronizing:  If a valid block number is received, it
will be: 1) the expected one, in which case everything is fine;
or 2) a repeat of the previously received block.  This should
be considered OK, and only indicates that the receivers <ack>
got glitched, and the sender re-transmitted; 3) any other block
number indicates a fatal loss of synchronization, such as the
rare case of the sender getting a line-glitch that looked like
an <ack>.  Abort the transmission, sending a <can>

---- 4C. SENDING PROGRAM CONSIDERATIONS.

    While waiting for transmission to begin, the sender has
only a single very long timeout, say one minute.  In the
current protocol, the sender has a 10 second timeout before
retrying.  I suggest NOT doing this, and letting the protocol
be completely receiver-driven.  This will be compatible with
existing programs.
    When the sender has no more data, it sends an <eot>, and
awaits an <ack>, resending the <eot> if it doesn't get one. 
Again, the protocol could be receiver-driven, with the sender
only having the high-level 1-minute timeout to abort.


-------- 5. DATA FLOW EXAMPLE INCLUDING ERROR RECOVERY

Here is a sample of the data flow, sending a 3-block message.
It includes the two most common line hits - a garbaged block,
and an <ack> reply getting garbaged.  <xx> represents the
checksum byte.

SENDER					RECEIVER
				times out after 10 seconds,
			<---		<nak>
<soh> 01 FE -data- <xx>	--->
			<---		<ack>
<soh> 02 FD -data- xx	--->	(data gets line hit)
			<---		<nak>
<soh> 02 FD -data- xx	--->
			<---		<ack>
<soh> 03 FC -data- xx	--->
   (ack gets garbaged)	<---		<ack>
<soh> 03 FC -data- xx	--->		<ack>
<eot>			--->
			<---		<ack>

-------- 6. PROGRAMMING TIPS.

* The character-receive subroutine should be called with a
parameter specifying the number of seconds to wait.  The
receiver should first call it with a time of 10, then <nak> and
try again, 10 times.
  After receiving the <soh>, the receiver should call the
character receive subroutine with a 1-second timeout, for the
remainder of the message and the <cksum>.  Since they are sent
as a continuous stream, timing out of this implies a serious
like glitch that caused, say, 127 characters to be seen instead
of 128.

* When the receiver wishes to <nak>, it should call a "PURGE"
subroutine, to wait for the line to clear.  Recall the sender
tosses any characters in its UART buffer immediately upon
completing sending a block, to ensure no glitches were mis-
interpreted.
  The most common technique is for "PURGE" to call the
character receive subroutine, specifying a 1-second timeout,
and looping back to PURGE until a timeout occurs.  The <nak> is
then sent, ensuring the other end will see it.

* You may wish to add code recommended by Jonh Mahr to your
character receive routine - to set an error flag if the UART
shows framing error, or overrun.  This will help catch a few
more glitches - the most common of which is a hit in the high
bits of the byte in two consecutive bytes.  The <cksum> comes
out OK since counting in 1-byte produces the same result of
adding 80H + 80H as with adding 00H + 00H.
 9-Feb-84 18:39:11-MST,711;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Thu 9 Feb 84 18:39:08-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  7 Feb 84 20:40 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  7 Feb 84 20:30 EST
Date:     Tue, 7 Feb 84 20:25:02 EST
From:     BRINT <abc@brl-bmd>
To:       Mike Ciaraldi <ciaraldi@rochester.arpa>
cc:       INFO-CPM@mit-mc.arpa, POURNE@mit-mc.arpa
Subject:  Re:  BYTE arrived...

IEEE Spectrum arrived yesterday; I saw someone with a copy
last week.  You can't get it on the newsstands.

(Who cares?  Who cares when your BYTE arrived?  Is that the
most interesting thing that happened to you today?  What a
pity!)

 9-Feb-84 20:46:37-MST,584;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Thu 9 Feb 84 20:46:34-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  8 Feb 84 3:58 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  8 Feb 84 3:46 EST
Date: 8 February 1984 03:32 EST
From: Jerry E. Pournelle <POURNE@mit-mc>
Subject:  Turbo Pascal
To: Brzozowski%his-phoenix-multics.arpa@brl
cc: info-cpm@brl
In-reply-to: Msg of Tue 7 Feb 84 14:09 MST from Brzozowski%his-phoenix-multics.arpa at BRL.ARPA

it gets delivered in reaqsonable time and it's good stuff.

14-Feb-84 08:17:29-MST,1124;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 14 Feb 84 08:17:21-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  9 Feb 84 9:48 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  9 Feb 84 9:34 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 9 Feb 84 6:25-PST
Date: 8 Feb 84 8:28:41-PST (Wed)
To: info-cpm@brl
From: hplabs!hao!seismo!rochester!rocksvax!dave@ucb-vax
Subject: Re: Floppies on VAX
Article-I.D.: rocksvax.1643
In-Reply-To: Article <16380@sri-arpa.UUCP>

We got that here, woork great... Probably won't work on a 750, they have
no floppy disk drive built in.   The thing is painfully slow however, no
fault of the program, just the RX01 interface in the VAX, which is basically
connected via RS232 to the PDP11 which talks through a byte or something in
the VAX.  Hokey but it was only intended to boot the machine and run
diagnostics.

We use MODEM7 on an 820 now, because it goes a bit faster....
-- 
Dave

Arpa: Sewhuk.HENR@PARC-MAXC.ARPA
uucp: {allegra, rochester, ritcv, ritvp, amd70, sunybcs}!rocksvax!dave
14-Feb-84 08:18:39-MST,1067;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Tue 14 Feb 84 08:18:32-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  8 Feb 84 10:13 EST
Received: From Ucb-Vax.ARPA by BRL via smtp;  8 Feb 84 10:07 EST
Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.22/4.22)
	id AA20267; Wed, 8 Feb 84 07:00:58 pst
Received: from ucbruby.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA
	(4.13/4.13.1) id AA10495; Wed, 8 Feb 84 07:07:50 pst
Received: by ucbruby.CC.Berkeley.ARPA
	(4.14/4.13) id AA26032; Wed, 8 Feb 84 07:07:46 pst
Date: Wed, 8 Feb 84 07:07:46 pst
From: phil%euler@BRL.ARPA
Message-Id: <8402081507.AA26032@ucbruby.CC.Berkeley.ARPA>
To: ruby.info-cpm@brl
Subject: FORTH for the TRS-80 Model 100

     In the February Byte (yes, a subscription copy), the "Microbytes"
column mentions that American Micro Products has introduced a $99.95 MVP
FORTH for the model 100.  Hope this helps -- I don't have an address for
AMP.

					Phil
				(still jlapsley%D.CC@Berkeley)
14-Feb-84 09:39:20-MST,1265;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Tue 14 Feb 84 09:39:13-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  8 Feb 84 16:13 EST
Received: From Rochester.ARPA by BRL via smtp;  8 Feb 84 15:45 EST
Received: by sen.rochester (3.327.3N) id AA06883; 8 Feb 84 15:45:42 EST (Wed)
Received: by cay.Rochester (3.327.3N+) id AA14096; 8 Feb 84 15:42:24 EST (Wed)
Message-Id: <8402082045.6883@sen.rochester>
Date: 8 Feb 84 15:45:42 EST (Wed)
From: Mike Ciaraldi <ciaraldi@Rochester.ARPA>
Subject: Z-100 Terminal emulation
To: info-cpm@brl.ARPA

I have encountered a problem trying to run Emacs on a VAX/Unix system
using a Z-100 as a terminal.
I am running MODEM712 under CP/M-85, with the flag set which
allows control characters to get through to the screen
(rather than being filtered out, which is the default).
The Unix system (BSD 4.1c) thinks the terminal is an H-19.

When I start up Emacs, everything is correct except that
a "Y6" appears in the upper left corner of the screen.
The cursor controls, etc. work all right.
Does anyone know if there is a bug in the Z-100's emulation
of the H-19, or maybe a problem in the
standard Termcap?

Mike Ciaraldi
ciaraldi@rochester
14-Feb-84 09:48:50-MST,617;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 14 Feb 84 09:48:47-MST
Date:     Tue, 14 Feb 84 2:35:29 EST
From:     Michael John Muuss <mike@amsaa>
To:       INFO-CPM@amsaa
Subject:  Change of Distribution Machine

To more evenly distribute the load of transmitting all the mailing lists,
the INFO-CPM list is now being transmitted by host AMSAA, rather than
host BRL-VGR.

Contributions to the list should still be mailed to

	< INFO-CPM @ BRL >

and requests of the moderator should be mailed to

	< INFO-CPM-REQUEST @ BRL >

Best,
 -Mike Muuss
14-Feb-84 09:55:52-MST,661;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 14 Feb 84 09:55:48-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  9 Feb 84 5:19 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  9 Feb 84 5:13 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 9 Feb 84 1:55-PST
Date: 28 Jan 84 20:03:26-PST (Sat)
To: info-cpm@brl
From: decvax!duke!phs!jtb@ucb-vax
Subject: Re: ut-ngp.241: SIMTEL CP/M ARCHIVES
Article-I.D.: phs.2186

I would also like a copy of any instructions on ftping files from
SIMTEL perhaps someone could post them to the news.?
Jose Torre-Bueno
decvax!duke!phs!jtb
14-Feb-84 10:01:44-MST,1382;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 14 Feb 84 10:01:39-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  9 Feb 84 9:30 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  9 Feb 84 8:59 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 9 Feb 84 5:56-PST
Date: 29 Jan 84 16:40:36-PST (Sun)
To: info-cpm@brl
From: hplabs!intelca!proper!forcm5!jr@ucb-vax
Subject: Are locations 57H through 59H used?
Article-I.D.: forcm5.119

Hi.  I'm interested in finding out whether the addresses 57H through 59H in
the base page ("System Parameter Area") are used in any variant of CP/M.  I'm
especially interested in whether CP/M Plus uses these addresses.  (They're
listed as "reserved" in the CP/M 2.2 and MP/M II manuals).

If anyone's interested in what I want to do with these addresses, think about
argv[0] (that's the way the command name is passed to the program, for those
of you who don't recognize that from C and UNIX)...  I'd like to propose that
those addresses be reserved for that purpose (along the lines of the way MP/M
II stores info about the passwords from a command line), but I need to find out
if there are any conflicts first...

				Thanks in advance!
-- 
				JR (John Rogers)
				UUCP: forcm5!jr, fortune!jr, proper!jr
				CompuServe: 70140,213  MCI Mail: jrhpp
14-Feb-84 10:28:04-MST,633;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Tue 14 Feb 84 10:28:00-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  8 Feb 84 23:16 EST
Received: From Sumex-Aim.ARPA by BRL via smtp;  8 Feb 84 23:08 EST
Date: Wed 8 Feb 84 20:09:10-PST
From: Leslie Zatz <ZATZ@SUMEX-AIM.ARPA>
Subject: DEC RAINBOW
To: info-cpm@BRL.ARPA

   I need to transfer an addresss list now on a DEC Rainbow
to my out off date system and would like to do via telephone
using MDM. Does anyone have a DEC Rainbow who would be willing to load up and permit me to 
call to transsfer?
-------
14-Feb-84 10:33:00-MST,519;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 14 Feb 84 10:32:56-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  9 Feb 84 17:22 EST
Received: From Aerospace.ARPA by BRL via smtp;  9 Feb 84 17:11 EST
Date:           Thu, 9 Feb 84 14:10:57 PST
From:           William T. Overman <overman@aerospace>
To:             info-cpm@brl
Subject:        squeeze on tops-20

Does anyone know of a version of SQ (squeeze) running on TOPS-20?

Thanks,
Bill
14-Feb-84 10:51:25-MST,1079;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Tue 14 Feb 84 10:51:21-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  9 Feb 84 1:50 EST
Received: From Csnet-Cic.ARPA by BRL via smtp;  9 Feb 84 1:35 EST
Date: 8 Feb 1984 02:04:25-EST
From: erh%virginia@csnet-relay
Return-Path: <erh%Virginia@CSNet-Relay>
Subject: Turbo Pascal
To: info-cpm@brl, mmdf%virginia@csnet-relay
Via:  Virginia; 9 Feb 84 0:17-EST

Read Jerry's comments about Turbo in Feb. Byte.  By the way, I disagree
with his gripes concerning Borland's policy of charging extra $100 for
unlimited object code distribution.  Why didn't Jerry complain about
Sorcim not letting people distribute freely the PRUN.COM file (i.e. the
p-code interpreter that comes with Pascal/M)?  In a sense, this would
equivalent, as linked object code is made in large part of library
procedures.  Now, quite possibly the the general trend is toward automatic
licensing of compiler's output.  I only think that Jerry's flames were
exagerated.
--Ed Howorka.

14-Feb-84 11:15:09-MST,766;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 14 Feb 84 11:15:05-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  14 Feb 84 12:45 EST
Received: From Rochester.ARPA by BRL via smtp;  14 Feb 84 12:33 EST
Received: by sen.rochester (3.327.3N) id AA13612; 14 Feb 84 11:40:05 EST (Tue)
Received: by cay.Rochester (3.327.3N+) id AA00389; 14 Feb 84 12:31:34 EST (Tue)
Message-Id: <8402141640.13612@sen.rochester>
Date: 14 Feb 84 11:40:05 EST (Tue)
From: Mike Ciaraldi <ciaraldi@Rochester.ARPA>
Subject: Modems Wanted Update
To: Mike Ciaraldi <ciaraldi@Rochester.ARPA>, info-cpm@brl.ARPA

I found the ad I was looking for--
USRobotics Password for $315 from S-100, inc.
in Arizona.
see February Byte.
14-Feb-84 11:15:38-MST,801;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 14 Feb 84 11:15:35-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  9 Feb 84 22:45 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  9 Feb 84 22:32 EST
Date: 9 February 1984 22:33 EST
From: Eric Stork <STORK@mit-mc>
Subject: HELP ON MODEM7XX FOR EAGLE II
To: INFO-CPM@brl
cc: STORK@mit-mc


A friend in Los Angeles has an Eagle 2 and needs
a version of MODEM7 to get started on communications.
Would appreciate a response to STORK % MIT-MC if someone
has this set up, so I can get you together with my LAX friend.
Or, if you're in the LAX area, call Ernie Rosenberg at
(818)501-0736 evenings, or at the office (213)486-6098.
He'll sure appreciate any help getting started.

14-Feb-84 13:37:44-MST,935;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 14 Feb 84 13:37:39-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  10 Feb 84 0:18 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  10 Feb 84 0:06 EST
Date: 10 February 1984 00:07 EST
From: Stephen C. Hill <STEVEH@mit-mc>
Subject:  Making WordStar 3.3 come up faster
To: WANCHO@stl-host1
cc: STEVEH@mit-mc, info-cpm@brl
In-reply-to: Msg of 29 Jan 1984  10:10 CST (Sun) from WANCHO at STL-HOST1

Upon re-reading my preceeding message, I discovered a typo
(Murphy at work again!)  The actual instructions that should
have been placed at 3CEB are JR 38 and NOP (18 38 00).  The
last NOP is just placed there for neatness, since I am
replacing a three byte instruction with a two byte.  Please
note that the relative jump is a 38 NOT a 3A, as previously
reported.  Please correct the WS files at SIMTEL.  Thx.

15-Feb-84 08:15:18-MST,856;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Wed 15 Feb 84 08:15:15-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  7 Feb 84 19:41 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  7 Feb 84 19:28 EST
Received: by sen.rochester (3.327.3N) id AA17033; 7 Feb 84 19:29:22 EST (Tue)
Received: by cay.Rochester (3.327.3N+) id AA12626; 7 Feb 84 19:25:57 EST (Tue)
Message-Id: <8402080029.17033@sen.rochester>
Date: 7 Feb 84 19:29:22 EST (Tue)
From: Mike Ciaraldi <ciaraldi@Rochester.ARPA>
Subject: Re:  BYTE arrived...
To: INFO-CPM@mit-mc.ARPA, POURNE@mit-mc.ARPA

Mirabile dictu, my February Byte arrived here in Rochester
on Thursday, Feb. 2.  Newsstand copies arrived earlier that week.
This is a new record for promptness on my subscription copy.
Mike Ciaraldi
ciaraldi@rochester

15-Feb-84 08:15:44-MST,2304;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Wed 15 Feb 84 08:15:38-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  7 Feb 84 20:20 EST
Received: From Rochester.ARPA by BRL via smtp;  7 Feb 84 20:07 EST
Received: by sen.rochester (3.327.3N) id AA17266; 7 Feb 84 20:08:19 EST (Tue)
Received: by cay.Rochester (3.327.3N+) id AA12663; 7 Feb 84 20:05:00 EST (Tue)
Message-Id: <8402080108.17266@sen.rochester>
Date: 7 Feb 84 20:08:19 EST (Tue)
From: Mike Ciaraldi <ciaraldi@Rochester.ARPA>
Subject: Re: Modems wanted
To: info-cpm@brl.ARPA

Some prices I have seen:
USRobotics Password, $339 from Image Computers, P.O.Box
1164, Cardiff, CA 92007   (619) 942-7373

Hayes Smartmodem 1200  $469 from The Byte General,
3 Sierks Lane, Roslyn Harbor NY 11576
(516) 625-0920 orders; (516) 484-6391 technical.

Signalman Mark XII $329 from Aldershot's, 1103 High Vista Dr.,
Richardson TX 75080
(800) 527-4235 outside Texas, (214) 235-0798 inside Texas.

Hayes 1200 $469 from Longwood Computing/Mail Order Heaven,
205 Birch Drive, Roslyn NY 11576  (516) 944-6117. They
also have the new Prometheus Modem/Chronograph. No price
listed.


Rixon R212A (highly reviewed in newest Byte, I think).
$455 from Micro Trend, 2001 Kirby, Suite 906, Houston
TX 77019.

Hayes 1200 $475 from Computers Anonymous, 278 Plandome Rd.,
Manhasset NY 11030  (516) 365-7982 voice
or 625-0160 modem.

Hayes 1200 $485 from Computer Connection, 12841 S. Hawthorne Blvd,
No. 585, Hawthorne CA 90250   (213) 514-9019.


US Robotics Password $340, Hayes 1200 $493 from Knowledge
Systems, (213) 344-4455, 19707 Ventura Blvd., Woodland Hills Ca 91354.

Rixon $469, Hayes $499 from CFX Disk Systems, POBox 90152,
Norcross GA 30092 (800) 241-4783 or (404) 255-3377.

These prices are fram ads in either January Byte or
February Computer Shopper.

*******

In addition to this, here in Rochester we arranged a
group buy through Marchese Enterprises for Passwords
at $325 each in blocks of at least five.

And, I remember seeing the Password at $315, I think somewhere
in December or January Byte, but now I can't find the ad.

Hope this helps. I have no connection with any of
these companies.

Mike Ciaraldi
ciaraldi@rochester
15-Feb-84 08:17:28-MST,1192;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Wed 15 Feb 84 08:17:23-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  8 Feb 84 10:13 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  8 Feb 84 10:10 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 8 Feb 84 6:57-PST
Date: 6 Feb 84 10:08:03-PST (Mon)
To: info-cpm@brl
From: ihnp4!afinitc!rbm@ucb-vax
Subject: DRI C Problems
Article-I.D.: afinitc.171

     The CP/M-86 version of the Digital Research C compiler is full of
floating-point bugs.  Since we are planning to do a good amount of floating- 
point computations the Digital Research compiler is unacceptable to us.
We are thus shopping for a compiler once again.  If anyone knows of any
other compilers which meet the following requirements I would appreciate
hearing from you:

          - is a full C implementation (i.e. Kernighan and Ritchie)
          - runs in a CP/M-86 environment
          - has more than 64K of data space

               Rick Moll
               ..!ihnp4!afinitc

               Affinitec
               2252 Welsch Ind. Ct.
               St. Louis, MO 63146
15-Feb-84 08:26:00-MST,564;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Wed 15 Feb 84 08:25:57-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  9 Feb 84 1:50 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  9 Feb 84 1:38 EST
Date: 8 Feb 1984 01:49:37-EST
From: erh%virginia@csnet-relay
Return-Path: <erh%Virginia@CSNet-Relay>
Subject: BYTE arrived...
To: INFO-CPM@mit-mc, mmdf%virginia@csnet-relay
Via:  Virginia; 9 Feb 84 0:17-EST

Tuesday 7 February in Charlottesville VA (only two weeks after the 
January copy).

15-Feb-84 09:10:03-MST,831;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 15 Feb 84 09:09:48-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  10 Feb 84 10:42 EST
Received: From Radc-Tops20.ARPA by BRL via smtp;  10 Feb 84 9:39 EST
Date: Fri 10 Feb 84 09:30:03-EST
From: Gern <GUBBINS@RADC-TOPS20.ARPA>
Subject: INFO-HZ100 birth pains
To: HZ100-Lovers: ;
cc: INFO-MICRO@BRL.ARPA, INFO-CPM@BRL.ARPA


Birth Pains:  I am working on our mailer.  The following people
have been dropped off the list due to mailer problems, their mailboxes,
or my own folly with this systems editor.  Please resubmit your address:

UMICH Z-00_people
Brahms
Elder WPAFB (no mailbox)
NYU-INFO-HZ100
hutchinson

All unix addresses (with ! in them) who did not receive this.   Thanx.

Gern
-------
15-Feb-84 11:09:58-MST,688;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 15 Feb 84 11:09:55-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  10 Feb 84 12:33 EST
Received: From Parc-Maxc.ARPA by BRL via smtp;  10 Feb 84 12:13 EST
Date: Fri, 10 Feb 84 08:54 PST
From: Eldridge.es@PARC-MAXC.ARPA
Subject: Random number generator wanted
To: info-cpm@brl.ARPA
cc: es820ug^.es@PARC-MAXC.ARPA, Eldridge.es@PARC-MAXC.ARPA
Reply-To: Eldridge.es@PARC-MAXC.ARPA

Does anyone have a linear congruential random number generator
implemented in C using 32-bit words (long)?  I would appreciate hearing
about it.

George (Eldridge.es@PARC-MAXC.ARPA)

15-Feb-84 13:32:55-MST,638;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 15 Feb 84 13:32:51-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  14 Feb 84 17:04 EST
Received: From Rand-Relay.ARPA by BRL via smtp;  14 Feb 84 16:58 EST
Date: 14 Feb 1984 11:45:58-PST (Tuesday)
From: Jim moore <MOORE.LOSANGEL.IBM@rand-relay>
Return-Path: <MOORE.LOSANGEL.IBM-SJ@Rand-Relay>
Subject: suggest new mailing list
To: info-cpm@brl
Via:  IBM-SJ; 14 Feb 84 13:10-PST

For the obvious reasons, why don't the interested parties initiate a new
mailing list:
 
     INFO-WHEN-MY-BYTE-ARRIVES
 
Thanks,
 
Jim
15-Feb-84 13:33:54-MST,870;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 15 Feb 84 13:33:51-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  14 Feb 84 23:53 EST
Received: From Sumex-Aim.ARPA by BRL via smtp;  14 Feb 84 23:50 EST
Date: Tue 14 Feb 84 20:44:14-PST
From: Leslie Zatz <ZATZ@SUMEX-AIM.ARPA>
Subject: David Ragozin
To: info-cpm@BRL.ARPA

Thanks for your offer of help. I can not reach you from
SUMEX at entropy!rag@uw-beaver. I get a message of no such local user.
I will try again. What I want to do is to send you
diskettes with a mailing list, then at your convenience,
call you and receive them over the phone. If agreeable,
please give me you address and phone number.
   Leslie M. Zatz, MD, Radiology Dept (114)
   VAMC, Palo Alto, CA  94304
I am going to try sending message to you direct again.
-------
15-Feb-84 13:34:00-MST,488;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 15 Feb 84 13:33:57-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  14 Feb 84 23:53 EST
Received: From Sumex-Aim.ARPA by BRL via smtp;  14 Feb 84 23:50 EST
Date: Tue 14 Feb 84 20:39:22-PST
From: Leslie Zatz <ZATZ@SUMEX-AIM.ARPA>
Subject: Re:  DEC RAINBOW
To: info-cpm@BRL.ARPA
In-Reply-To: Message from "ENTROPY!rag (David Ragozin)" of Tue 14 Feb 84 09:56:39-PST


-------
15-Feb-84 13:57:30-MST,1865;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 15 Feb 84 13:57:24-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  10 Feb 84 20:47 EST
Received: From Parc-Maxc.ARPA by BRL via smtp;  10 Feb 84 20:43 EST
From: DGILBERT.ES@PARC-MAXC.ARPA
Date: 10 Feb 84 17:37:34 PST
Subject: WordStar with ZCPR2
To: BURTON@BERKELEY.ARPA
cc: INFO-CPM@BRL.ARPA, DGILBERT.ES@PARC-MAXC.ARPA

		USING WORDSTAR UNDER ZCPR2

Programs like WordStar are a problem, in that one would like to keep 
only 1 set of files and be able to use tham from any USER area.  
WordStar always looks for its overlay files on drive A, if not on the 
default drive.  Unfortunately, there is no provision for specifying 
the USER area, so if your in drive G, user 7, WordStar will only 
check drive A, user 7 for the overlays if not on drive F, user 7.

There is a solution.

A public domain program called 'DUPUSR' will create a duplicate 
directory entry on your CP/M disk, but a new User Number.  So put the 
WordStar files on Drive A, User 0 (physical drive E).  Create 
duplicate entries for the overlay files for A1, A2, A3, ... to your 
highest user number used.  Each directory entry actually points to 
the same allocation numbers, so there is only one actual copy of the 
file.

This system works fine.  I can be in any user number, on any disk, 
and run WordStar without a problem.

There is only one danger.  If you ever erase one of the directory 
entries that are duplicated in another user area, CP/M will assume it 
can reuse the allocation groups thus 'freed', unless you do a disk 
reset by 'Warm Boot'.  By always doing a 'warm boot' after erasing an 
entry, no problem occurs.  It's better than having duplicate files in 
every user area and wasting lots of good ol' disk space.

Doug.

15-Feb-84 14:12:47-MST,908;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 15 Feb 84 14:12:42-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  15 Feb 84 15:38 EST
Received: From Parc-Maxc.ARPA by BRL via smtp;  15 Feb 84 11:25 EST
Date: Wed, 15 Feb 84 08:20 PST
From: Eldridge.es@PARC-MAXC.ARPA
Subject: L80 patches
To: info-cpm@brl.ARPA
cc: es820ug^.es@PARC-MAXC.ARPA
Reply-To: Eldridge.es@PARC-MAXC.ARPA

I am using Link-80 3.44 09-Dec-81.  It appears that L80 does a disk
reset and relogs the disk every time it accesses a new REL file.  This
becomes very time consuming when you have a hard disk with a large
directory since it must regenerate the allocation map every time it
resets the disk.

Is there a patch to modify this behavior?  It seems that all the disk
relogging is unnecessary and could be patched out.

George (Eldridge.es@PARC-MAXC.ARPA)

15-Feb-84 14:18:53-MST,2094;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 15 Feb 84 14:18:46-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  10 Feb 84 21:33 EST
Received: From Ucb-Vax.ARPA by BRL via smtp;  10 Feb 84 21:26 EST
Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.22/4.22)
	id AA08621; Fri, 10 Feb 84 18:26:49 pst
Received: from ucbpopuli.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA
	(4.14/4.13.1) id AA14535; Fri, 10 Feb 84 18:22:53 pst
Received: by ucbpopuli.CC.Berkeley.ARPA
	(4.14/4.13) id AA00571; Fri, 10 Feb 84 15:48:55 pst
Date: Fri, 10 Feb 84 15:48:55 pst
From: cgr%ucbpopuli.CC@berkeley
Message-Id: <8402102348.AA00571@ucbpopuli.CC.Berkeley.ARPA>
To: info-cpm@brl
Subject: SUBMIT and lowercase


     I have a question concerning SUBMIT and XSUB. My application
involves creating text files on a KayPro II (running CP/M v.  2.2) and
uploading them to a Unix system.  I would like to create a variety of
SUBMIT files to do various kinds of error correction automatically
(remove spaces at beginning and end of lines, merge multiple spaces
between words, etc., etc.).  Unfortunately, SUBMIT seems to
automatically transform my lowercase patterns into uppercase before
passing them on to ED (which can handle lowercase patterns); thus, the
following script will change "AFRICA" to "ASIA" but will not change
"AFrica" to "Africa".

     XSUB
     ED TEXT.MSS
     #A
     B
     #SAFRICA^ZASIA^Z
     B
     #SAFrica^ZAfrica^Z
     E

Words fail me.  Am I missing something?  Surely serious programmers
wouldn't write a major system program that can't handle lowercase?... 

     Is there any way to circumvent this "feature"? I'm no CP/M
wizard, but I'm willing to get my hands dirty if there's any kind of
kludge that will let me do what I want.  All suggestions gratefully
considered.  If there's sufficient interest, I'll summarize responses
for the net. 

                                   John Hevelin
                                   ucbvax!cgrucbpopuli

15-Feb-84 15:16:56-MST,2558;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 15 Feb 84 15:16:47-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  11 Feb 84 2:09 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  11 Feb 84 1:56 EST
Date: 10 Feb 84 22:31:17 PST (Fri)
To: info-cpm@mit-mc
cc: young@uci-750b
Subject: Turbo Pascal-- first impressions
From: Michal Young <young@uci-750a>

Turbo Pascal arrived yesterday.  I'll share some first impressions now
and give a better review when I've used it for a while.

First-- it is very near standard.  Get and Put are not implemented, the
IO primitives are instead Read and Write.  The heap is really a stack
and storage is returned by using mark and release instead of dispose.
Goto may not leave a block (this may be a problem for error recovery).
Functions and procedures may not be passed as parameters. 'Packed' is 
allowed but meaningless, and pack and unpack are not provided.  

There are numerous extensions, but they are well thought out mostly and 
do not screw up the syntax or semantics of the standard portion of the
language.  For instance, initializers are provided by an extension to
the const declaration.  Structures and arrays can be initialized this
way.  Strings up to 255 characters are allowed.  

A real attempt has been made to provide a programming environment rather
than just a compiler.  Provided the program and pascal system both fit
in memory, you can edit a program, compile and run it, and edit again
to fix an error without leaving the environment.  And no annoying waits
for overlays to load from disk, either-- compiler, editor, and program
somehow fit in memory all at once.  When either a syntax error or a run-time
error is detected, you wind up back in the editor with the cursor at 
the error.  If you have to run your program from outside the pascal 
system (because it is too big to fit with everything else in memory),
you can still find the source line in error.  You reenter the pascal
system and tell it the program counter address, and it re-compiles
until it comes to that address.  Pretty slick.  There are a few
rough edges, but I haven't ever seen a compiler (not interpreter)
this nice to work with.

The documentation is good.  250+ pages in a paperback book, reasonably
well written but not outstanding.  This same manual covers CP/M-80,
CP/M-86, and MS-DOS versions.  Except for BIOS level diddling (which
turbo will allow), it looks to be portable.  

Michal Young
young@uci

15-Feb-84 15:34:42-MST,1531;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 15 Feb 84 15:34:34-MST
Received: From Brl-Bmd.ARPA by BRL-VGR via smtp;  11 Feb 84 8:10 EST
Date:     Sat, 11 Feb 84 8:01:11 EST
From:     Charlie Strom (NYU) <strom@brl-bmd>
To:       DGILBERT.ES@parc-maxc.arpa
cc:       INFO-CPM@brl-vgr
Subject:  SETDRU


Another solution to the problem of multiple overlays is a program called
SETDRU, authored by Mike Rubenstein. SETDRU is a BDOS filter which allows
remapping of up to 8 file specifications (unambiguous or ambiguous)
so that a program can access any other files on any drive/user. This
works very well with Wordstar, and allows me to have a small (<1K)
program called EDIT.COM on my ZCPR2 root du. Invoking EDIT will call
Wordstar which could be on any other du as well as its overlays which
could be on the same or yet another du. If ZCPR is not installed, one
must have multiple copies of EDIT.COM, but not of WS or its overlays.

SETDRU actually consists of a user interface and two filters, one
that allows the filter to be bound to the .COM program of
interest and another which calls the program. The latter is required
for programs such as WS that test its integrity after re-entry from the
R command.

SETDRU is in Z80 code. I will be completing an 8080 conversion in a
few days and will upload relevant files to Simtel at that time and will
post a notice to the list. I have run this program successfully under
CP/M Plus as well as 2.2.
15-Feb-84 15:57:56-MST,1755;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 15 Feb 84 15:57:49-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  15 Feb 84 15:58 EST
Received: From Rochester.ARPA by BRL via smtp;  15 Feb 84 15:51 EST
Received: by sen.rochester (3.327.3N) id AA15602; 15 Feb 84 15:51:01 EST (Wed)
Received: by cay.Rochester (3.327.3N+) id AA03199; 15 Feb 84 15:48:25 EST (Wed)
Message-Id: <8402152051.15602@sen.rochester>
Date: 15 Feb 84 15:51:01 EST (Wed)
From: Mike Ciaraldi <ciaraldi@Rochester.ARPA>
Subject: Re:  Need help designing homebrew system
To: info-cpm@brl.ARPA, menlo70!nsc!nessus@ucb-vax.ARPA

I would recommend some good books on designing digital and
computer hardware.

Don Lancaster's "TTL Cookbook" covers the basics, and I think
he has one for microprocessors now.

Sol Libes and someone whose name I forgot have a book
on interfacing to the S-100 bus. I realize you are using the
Multibus, but the principles are similar.

You might also get the books Godbout publsihes which collect
all the technical manuals of their products.

Intel makes several Multibus CPU, memory, and peripheral boards.
I think they will send you tech manuals, including schematics, for
free.


In addition, if you want to run CP/M 3.0 you will need
bank switching so the CPU can address more than 64K of memory.
Just having a latch for hig-order address lines may not
be enough.


finally, for bringing up the software, look at the sample
BIOS's in the SIMTEL archives. It is much easier to
produce a working CP/M operating systemif you have access
to another CP/M system with assembler, editor, and
compatible disk drives.

Good luck!

Mike Ciaraldi
ciaraldi@rochester
15-Feb-84 18:05:03-MST,1763;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 15 Feb 84 18:04:57-MST
Date:     Wed, 15 Feb 84 19:50:11 EST
From:     Dave Towson (info-cpm) <cpmlist@amsaa>
To:       info-cpm@amsaa
Subject:  Mail problems at BRL.


----- Forwarded message # 1:

Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  13 Feb 84 19:42 EST
Received: From Rand-Unix.ARPA by BRL via smtp;  13 Feb 84 19:28 EST
From: vortex!lauren@rand-unix
Date: Mon, 13-Feb-84 15:34:06-PST
Sender: Lauren Weinstein <vortex!lauren@rand-unix>
Subject: lists
Message-ID: <8402131534.8779.2.VT2.2@vortex.UUCP>
To: UNIX-WIZARDS-REQUEST@brl, INFO-MICRO-REQUEST@brl, INFO-CPM-REQUEST@brl

Are these lists all healthy?  I got virtually no traffic over the weekend,
including messages I sent myself to all three lists.  I continue to get
copies of messages from people talking about their damn Byte 
subscriptions, however...

Thanks much for any info.

--Lauren--


----- End of forwarded messages

Lauren and all others on info-cpm - It has just been discovered that a mailer
bug was being triggered by mail rejected from Rand-Unix due to an upper/lower
case switch in the mailing list.  This has been fixed with a band-aid, and the
local mail people think things should be working okay now.  Also, to relieve a
serious mail-handling load on BRL-VGR, the list has been moved to my home
machine (yay!) AMSAA.  Mail to the list should now be addressed to info-cpm@brl or info-cpm@amsaa (take your pick).  Likewise, mail having to
do with list changes, additions, deletions or other such matters should go to
info-cpm-request@brl or @amsaa.  Sorry for the past inconvenience.



Dave Towson
info-cpm-request@amsaa


15-Feb-84 18:51:45-MST,1657;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 15 Feb 84 18:51:39-MST
Date:     Wed, 15 Feb 84 20:36:34 EST
From:     Dave Towson (info-cpm) <cpmlist@amsaa>
To:       info-cpm@amsaa
Subject:  [knutson:  Re: Z-100 Terminal emulation]


----- Forwarded message # 1:

Received: From Brl-Vgr.ARPA by AMSAA via smtp;  15 Feb 84 15:37 EST
Received: From Ut-Ngp.ARPA by BRL-VGR via smtp;  15 Feb 84 10:03 EST
Date: Wed, 15 Feb 84 09:05:18 cst
From: knutson@ut-ngp.ARPA
Posted-Date: Wed, 15 Feb 84 09:05:18 cst
Message-Id: <8402151505.AA19163@ut-ngp.ARPA>
Received: by ut-ngp.ARPA (4.22/3.14)
	id AA19163; Wed, 15 Feb 84 09:05:18 cst
To: info-cpm-request@BRL-VGR.ARPA
Subject: Re:  Z-100 Terminal emulation
Cc: ciaraldi@rochester.ARPA

I have set up a Z100 termcap entry that seems to work rather well.  It 
has been run on a line at upto 2400 baud without problems.

#	the following are termcap entries that have been modified
#	from /etc/termcap or are terminals that are used besides the
#	ones that were modified.
zc|z100c|h100c|z-100c|h-100c|heath/zenith z-100 pc with color monitor:\
	:vs=\Ex4\Em71:ve=\Ey4\Em70:tc=z100:
z1|z100|h100|z-100|h-100|heath/zenith z-100 pc:\
	:al=5*\EL:bs:cd=\EJ:ce=\EK:cl=5*\EE:cm=1*\EY%+ %+ :co#80:dc=1*\EN:\
	:dl=5*\EM:do=\EB:ei=\EO:ho=\EH:im=\E@:li#24:mi:nd=\EC:as=\EF:ae=\EG:\
	:ms:pt:sr=\EI:se=\Eq:so=\Ep:up=\EA:vs=\Ex4:ve=\Ey4:\
	:kb=^h:ku=\EA:kd=\EB:kl=\ED:kr=\EC:kh=\EH:kn#10:\
	:k0=\EJ:k1=\ES:k2=\ET:k3=\EU:k4=\EV:k5=\EW:\k6=\EP:k7=\EQ:\
	:k8=\ER:k9=\EOI:

						Jim Knutson
						knutson@ut-ngp


----- End of forwarded messages
16-Feb-84 08:00:17-MST,933;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 16 Feb 84 08:00:12-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  15 Feb 84 23:14 EST
Received: From Ut-Ngp.ARPA by BRL via smtp;  15 Feb 84 23:03 EST
From: mknox@ut-ngp.ARPA
Posted-Date: Wed, 15 Feb 84 22:01:30 CST
Message-Id: <8402160404.AA04631@ut-ngp.ARPA>
Received: by ut-ngp.ARPA (4.22/3.14)
	id AA04631; Wed, 15 Feb 84 22:04:59 cst
Date: Wed, 15 Feb 84 22:01:30 CST
To: info-cpm@brl.ARPA
Subject: IBM-PC CP/M-86 Kermit needed


I fear my first msg fell into a week long 'bit-bucket' which existed.  So
now I will ask again:

  Does anyone have an implementation of KERMIT for the IBM-PC under
  CP/M-86?  The only ones at Columbia seem to be for the RAINBOW and
  NEC-APC.  A crude job would still be useful to me, as long as it
  can send and receive binary files.

			thanks;
			MKNOX at UT-NGP
16-Feb-84 09:18:03-MST,687;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 16 Feb 84 09:17:59-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  16 Feb 84 4:30 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  16 Feb 84 4:21 EST
Date: 16 February 1984 04:21 EST
From: Jerry E. Pournelle <POURNE@mit-mc>
Subject:  Turbo Pascal-- first impressions
To: young@uci-750a
cc: INFO-CPM@mit-mc, young@uci-750b
In-reply-to: Msg of 10 Feb 84 22:31:17 PST (Fri) from Michal Young <young at uci-750a>

Turbo, most tell me, is pretty good, BUT:

do this

foo := 1.23 * 100
now take frac of foo.
It won't be zero.

They say they'll fix that real soon now

16-Feb-84 09:18:52-MST,1138;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 16 Feb 84 09:18:44-MST
Received: From Brl-Vgr.ARPA by AMSAA via smtp;  16 Feb 84 4:59 EST
Received: From Mit-Mc.ARPA by BRL-VGR via smtp;  16 Feb 84 4:52 EST
Date: 16 February 1984 04:53 EST
From: Jerry E. Pournelle <POURNE@mit-mc>
Subject:  writing w/o opening
To: ciaraldi@rochester
cc: w8sdz@brl, Info-Cpm@brl-vgr
In-reply-to: Msg of 24 Jan 84 15:06:00 EST (Tue) from Mike Ciaraldi <ciaraldi at Rochester.ARPA>

it's not. sigh
    Date: 24 Jan 84 15:06:00 EST (Tue)
    From: Mike Ciaraldi <ciaraldi at Rochester.ARPA>
    To:   Info-Cpm at brl-vgr.ARPA, w8sdz at brl.ARPA
    Re:   writing w/o opening

    Under MP/M, there is a checksum in the FCB.
    This gets set when you open the file, and you cannot
    read or write on the file unless this checksum is correct.
    So, the problem of wiping out your directory by not
    opening the file first should not occur.

    I don't know if this technique is used in newer products
    such as CP/M-86 or CP/M-Plus

    Mike Ciaraldi
    ciaraldi@rochester

16-Feb-84 09:31:06-MST,611;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 16 Feb 84 09:31:01-MST
Received: From Brl-Vgr.ARPA by AMSAA via smtp;  16 Feb 84 9:47 EST
Date:     Thu, 16 Feb 84 9:42:33 EST
From:     Mike Muuss <mike@brl-vgr>
To:       info-cpm@brl-vgr
Subject:  VAX UNIX <-> CPM program needed

I know that a VAX UNIX (4.2 BSD) program to read/write 8" CPM floppies
on the VAX 780 console floppy drive exists.  I find myself in the
embarrassing position of needing a copy for one of our users.
Can somebody please provide a copy, or pointers?
	Best,
	 -Mike Muuss
16-Feb-84 09:35:25-MST,985;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 16 Feb 84 09:35:16-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  10 Feb 84 3:36 EST
Received: From Sri-Unix.ARPA by BRL via smtp;  10 Feb 84 3:28 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 10 Feb 84 0:24-PST
Date: 9 Feb 84 11:18:13-PST (Thu)
To: info-cpm@brl
From: menlo70!nsc!nessus@ucb-vax
Subject: Need help designing homebrew system
Article-I.D.: nsc.623

     I am considering building a homebrew computer system and would like
to make it CP/M compatible.  Anyone have any ideas about designing such a
thing{hardware and software}?  The system will be using Multibus(tm) boards
and card cage.

     Please do not advise me to go and buy XYZ system.  My budget cannot afford
buying a computer.  I collected the necessary components{disks, RAM, and such
from my company electronics club.

					Kchula-Rrit
					!menlo70!nsc!nessus
16-Feb-84 09:36:09-MST,416;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 16 Feb 84 09:36:03-MST
Received: From Minet-Obl-Em.ARPA by BRL-VGR via smtp;  10 Feb 84 3:51 EST
Date: 10 February 1984 08:48 GMT
From: byard@minet-obl-em
Subject: 8 Mhz Engine
To: info-cpm@brl-vgr

Date: 10 Feb 1984 08:44:52 Z
Text: According to the latest issue of InfoWorld that's what Mac has.  Larry

16-Feb-84 09:43:13-MST,5218;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 16 Feb 84 09:42:58-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  12 Feb 84 5:44 EST
Received: From Rand-Unix.ARPA by BRL via smtp;  12 Feb 84 5:28 EST
From: vortex!lauren@rand-unix
Date: Sun, 12-Feb-84 00:40:50-PST
Sender: Lauren Weinstein <vortex!lauren@rand-unix>
Subject: Cure for Vadic Triple Modem Problem...
Message-ID: <8402120040.04737dVT2.1@vortex.UUCP>
To: INFO-MICRO@brl, INFO-CPM@brl, UNIX-WIZARDS@brl, TELECOM@mc

So bunky, you say you got yourself a Racal-Vadic triple modem
(3451-series) and you have some problems with it?  You say that sometimes
in auto-answer mode it seems to hang offhook, making it impossible for any 
new calls to arrive?  You say that when this happens it refuses to respond
to DTR and only resets if you cycle the power or fiddle with the mode
toggle switch (if you have one, that is)?  Is that what's bothering
you, bunky?

WELLLLL!  Lift up your head and greet the sun, 'cause a solution
does exist -- and it doesn't even involve hydrochloric acid or 
jackhammers!  

Seriously, though, many persons have reported problems with triple modems
getting into a strange wedged condition from which it is difficult
to escape.  Both manual dial and autodial triples have shown this 
behavior, which is characterized by the modem being offhook, sending
a 212 carrier, and having both the HS and DSR lights lit.  Only cycling
the power or performing a software reset (by flipping the toggle switch
between auto and manual on the autodial modems) will clear this condition;
the modem is oblivious to DTR.  After having this occur repeatedly on the
main Vortex dialup line, I started harassing the engineers up at
Racal.  Actually, they were quite helpful, once they realized that I knew
what I was talking about and hadn't plugged the RJ-11C phone plug into
an AC wall outlet!

After talking with three different engineers and having them duplicate
the problem on their test benches, we arrived at the cause of the problem
and a (simple) solution.  The problem is caused by a "hole" in the triple
modem protocol select algorithm.  Under certain random timing conditions,
the modem may be "fooled" into entering a pseudo-originate mode during 
its answer-mode operations.  The exact reasons are too complex to go
into here, but the cure is straightforward:

Inside the modem, option dip switch A1 is described by the manual
as:

"Attended/Unattended Disconnect -- Set to Attended [ON] for Auto Dial modems.
(Unattended setting relates to manual originate operation only.)"

DON'T YOU BELIEVE IT!  This switch also affects the handling of DTR
during answer mode processing.  The "normal" setting of this option
(as set by the "standard-options" switch A6) is ON (Attended).
This is WRONG for almost all operations.  For both auto-dial and
non-autodial triple modems, this option should normally be
set to OFF (Unattended).  The only side effect of this is that if
you attempt to use the modem in a MANUAL originate mode, you will
probably have to supply DTR at the RS232 interface (big deal!)
If you leave A1 OFF, the answer mode wedging problem should vanish!
Auto-dial operations on auto-dial modems should work as always.

NOTE: If your triple has switch A6 OFF, then "standard-options" mode
is ENABLED and the remaining A and B switches are ignored.  In order
to change the state of A1 to OFF, you must also turn switch A6 ON
to disable "standard-options" and make sure that all other switches are
set appropriately.

I recommend the following settings (some of these are NOT the
default settings):

A1  --  OFF  (Unattended -- fixes the answer wedge problem)
A2  --  OFF  (Do NOT respond to remote test) [do you want everyone in 
	     the universe "testing" your modem for you?]
A3  --  ON   (10 bit chars -- this is normal)
A4  --  ON   103 operation enabled
A5  --  OFF  (10 bit chars -- this is normal)
A6  --  ON   Disable standard-options (enables all other switches)
A7  --  ON   Auto-disconnect on loss of carrier enabled

B1  --  OFF  Local digital loopback select (ignored when not testing)
B2  --  OFF  DTR controlled from RS232 interface
B3  --  OFF  Originate and Answer modes allowed
B4  --  OFF  1204 bps speed (this is normal)
B5  --  ON   Auto-disconnect/Abort timer enabled
B6  --  OFF  Asynchronous operation
B7  --  ON   DSR off in test (ignored when not testing)

In addition, I recommend the following two jumper changes on the
BOTTOM pc board:

Insert jumper "r"  -- enable data rate indicator on RS232 pin 12
Remove jumper "ag" -- do not tie carrier detect high (RS232 pin 8)

------

The "wedged" condition mentioned above, being related to a rather
random timing window, is more likely to have been seen on modems
that have a high volume of calls than on low volume incoming lines.
However, it occurs frequently enough that I recommend the option
change for all triple modems being used for incoming calls.

Be sure to let me know if you have any questions about or problems with
this info.  I hope it's of some use, bunky...

--Lauren--

16-Feb-84 09:45:21-MST,683;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 16 Feb 84 09:45:17-MST
Received: From Ut-Ngp.ARPA by BRL-VGR via smtp;  12 Feb 84 21:17 EST
From: mknox@ut-ngp.ARPA
Posted-Date: Sun, 12 Feb 84 20:16:31 CST
Message-Id: <8402130218.AA02725@ut-ngp.ARPA>
Received: by ut-ngp.ARPA (4.22/3.14)
	id AA02725; Sun, 12 Feb 84 20:18:41 cst
Date: Sun, 12 Feb 84 20:16:31 CST
To: info-cpm@brl-vgr.ARPA
Subject: KERMIT :: CP/M-86


Does anyone have a version of KERMIT that runs on the IBM-PC under
CP/M-86?  Currently I have only found the NECAPC and RAINBOW versions.
Or am I going to need to 'pre-invent' the wheel?

					tnx
16-Feb-84 09:45:42-MST,1173;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 16 Feb 84 09:45:37-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  12 Feb 84 11:03 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  12 Feb 84 10:45 EST
Date: 12 February 1984 10:45 EST
From: Allan D. Plehn <PLEHN@mit-mc>
Subject: WARNING about Micro Design Associates.
To: INFO-CPM@mit-mc, INFO-MICRO@mit-mc
cc: PLEHN@mit-mc

Two friends of mine have purchased the disk controller board offered
by Micro Design Associates, Columbia, Mo.  Neither has been able to
make it work.  Efforts to contact the company have been futile; their
telephone has been disconnected.

The disk controller was advertised in a full page ad on page 19 of
the December 1983 issue of Microsystems Magazine.  It is a IEEE-696
(S-100) board and is supposed to run 5 1/4 and 8 inch drives
simultaneously.  The software provided is said to allow writing
sixteen specified soft sectored formats "and most others".

I'd appreciate hearing from others who may have ordered this
board.  Did yours work or not?  Have you discovered any fixes?
Etc. etc.
		PLEHN%MIT-MC

16-Feb-84 09:48:05-MST,1000;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 16 Feb 84 09:47:58-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  13 Feb 84 10:16 EST
Received: From Radc-Tops20.ARPA by BRL via smtp;  13 Feb 84 9:50 EST
Date: Mon 13 Feb 84 09:50:44-EST
From: Gern <GUBBINS@RADC-TOPS20.ARPA>
Subject: Mail relay for INFO-HZ100
To: INFO-HZ100@RADC-TOPS20.ARPA
cc: INFO-MICRO@BRL.ARPA, INFO-CPM@BRL.ARPA


With any luck, my TOPS20 system is patched to relay all INFO-HZ100@RADC-TOPS20
back out to the distribution list of approximately 60 persons.  This
is a test message.   All mailing list submissions  are to INFO-HZ100
@RADC-TOPS20 and requests to INFO-HZ100-REQUEST@RADC-TOPS20.  Any persons
or systems still not getting these messages as requested please rerequest
as my mailer choked on several addresses and UNIX addresses (corrected)
and you were hacked off the list to allow the system to work at all.

Thanx,

Gern
-------
16-Feb-84 11:03:23-MST,1396;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 16 Feb 84 11:03:17-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  13 Feb 84 16:58 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  13 Feb 84 15:49 EST
Received: from RU-BLUE.ARPA by RUTGERS.ARPA with PUP; 13 Feb 84 15:30:19 EST
Date: 13 Feb 84 15:29:37 EST
From: Charles <MCGREW@RU-BLUE.ARPA>
Subject: Need microcomputer "C" with UNIX IO
To: C-folks: ;

Hello,

	We're implementing a multi-user distributed adventure game
here and want to find a C with UNIX IO (as close to Berkely's as
possible would be nice).  We're soliciting for comments and
suggestions on the C compilers available.

	We are talking mostly about small machines, as in 6502, Z80 or
(gag me with advertising hype) 8088, but comments about C that runs on
non-unix 68000s would be appreciated.

	It should be a complete C through to enumeration types.  We
need to watch two ports at once (keyboard and communications), so some
kind of non-blocking IO or interrupt support would be a must.

Needed features:
	fseek 
	non-blocked IO (as in NO_DELAY in ioctl), or better,
	IO interrupt signals as on Berkely.

Desired features:
	enumeration types
	reasonably fast code (always a help, eh?)

Please send recommendations and comments to MCGREW@RU-BLUE.

Thanks,

Charles
-------

16-Feb-84 11:14:29-MST,644;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 16 Feb 84 11:14:25-MST
Received: From Brl-Vgr.ARPA by AMSAA via smtp;  16 Feb 84 12:57 EST
Received: From Uw-Beaver.ARPA by BRL-VGR via smtp;  16 Feb 84 12:44 EST
Date: 16 Feb 84 09:36:04 PST (Thu)
From: David Ragozin <ENTROPY!rag@BRL-VGR.ARPA>
Received: by ENTROPY.UUCP (3.320/4.2)
	id AA17521; 16 Feb 84 09:36:04 PST (Thu)
Subject: Re:  VAX UNIX <-> CPM program needed
Message-Id: <8402161736.AA17521@ENTROPY.UUCP>
To: info-cpm@brl-vgr, uw-beaver!mike@brl-vgr

I think its in SIMTEL20 under micro:<unix.cpm> with a name like
cpmutl.
16-Feb-84 11:15:09-MST,1326;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 16 Feb 84 11:15:00-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  13 Feb 84 19:42 EST
Received: From Ucb-Vax.ARPA by BRL via smtp;  13 Feb 84 19:22 EST
Received: from ucbjade.CC.Berkeley.ARPA (19002080) by UCB-VAX.ARPA (4.22/4.22)
	id AA29992; Mon, 13 Feb 84 13:32:15 pst
Received: from ucbruby.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA
	(4.14/4.13.1) id AA12265; Mon, 13 Feb 84 13:27:46 pst
Received: by ucbruby.CC.Berkeley.ARPA
	(4.14/4.13) id AA10447; Mon, 13 Feb 84 13:22:33 pst
Date: Mon, 13 Feb 84 13:22:33 pst
From: phil%euler@BRL.ARPA
Message-Id: <8402132122.AA10447@ucbruby.CC.Berkeley.ARPA>
To: ruby.info-cpm@brl
Subject: Minor gripe about advertisements

     It really irritates me when a company has what looks to be a nice
product (e.g, Turbo Pascal) and they claim it runs on "CP/M-80", but
they don't bother to mention that it's Z-80 only.  At the risk of
starting a general flame ("Anyone who wouldn't use a Z-80 is an
idiot"), anyone have any ideas on what percentage of the CP/M-80
market is Z-80?  Mail to me, I will summarize if it is of general
interest or if there is a great response.  Both are unlikely.

				Phil
		(jlapsley%D.CC@Berkeley, ignore the headers)
16-Feb-84 16:40:09-MST,566;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 16 Feb 84 16:40:05-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  13 Feb 84 23:28 EST
Received: From Sumex-Aim.ARPA by BRL via smtp;  13 Feb 84 23:16 EST
Date: Mon 13 Feb 84 20:12:53-PST
From: Leslie Zatz <ZATZ@SUMEX-AIM.ARPA>
Subject: dec RAINBOW
To: info-cpm@BRL.ARPA

Would someone with a DEC RAINBOW be able to load in a mailing
address list from a diskette and let me down-
load it using MDM via phone?
Leslie M. Zatz, Stanford
-------
17-Feb-84 08:46:55-MST,568;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 17 Feb 84 08:46:50-MST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  14 Feb 84 2:27 EST
Received: From Parc-Maxc.ARPA by BRL via smtp;  14 Feb 84 2:16 EST
From: ssalzman.es@PARC-MAXC.ARPA
Date: 14 Feb 84 2:15:08 EST
Subject: morrow md-3 & bye3
To: info-cpm@brl.ARPA
cc: ssalzman.es@PARC-MAXC.ARPA

Does anyone know of someone who is running BYE3 on a Morrow MD-3???
I need to get info on how to initialize the baud rate for it.
Thanks.

-Isaac.
17-Feb-84 18:42:04-MST,3147;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 17 Feb 84 18:41:56-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  17 Feb 84 20:17 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  17 Feb 84 20:14 EST
Received: from HIS-PHOENIX-MULTICS.ARPA by CISL-SERVICE-MULTICS.ARPA dial; 17-Feb-1984 20:06:12-est
Date:  Fri, 17 Feb 84 18:05 MST
From:  Kevin Kenny <Kenny%his-phoenix-multics.arpa@BRL.ARPA>
Subject:  Turbo Pascal--first impressions
Reply-To:  Kenny%PCO@CISL-SERVICE-MULTICS.ARPA
To:  "Dr Jerry E. Pournelle" <POURNE@MIT-MC.ARPA>
cc:  INFO-CPM@MIT-MC.ARPA
Message-ID:  <840218010529.999942@HIS-PHOENIX-MULTICS.ARPA>

The problem that you're describing (where frac (1.23 * 100) isn't zero)
is the usual truncation error in binary arithmetic.  If they say that
they'll fix it Real Soon Now, they either are lying, or mean that they
intend to foul things up further; to someone who's doing numerical
analysis, the result is CORRECT (if it's very close to 0 or 1; you
didn't say what the result is, just what it isn't).

[flame on] I am getting awfully tired of people who say that decimal
arithmetic is "inherently more accurate" than binary.  This claim is
absolute rubbish. [blowtorch valve off again].

The problem, of course, is that there is no exact binary representation
for 1.23; the expansion is a repeating string beginning
1.0011101011100001010001 with the last twenty digits repeating.  The
fact that 1.23 can be represented as a finite-length string in decimal
leads people to claim that "decimal is more accurate." But, try
representing 1/3 in either system.  It doesn't go, does it?  Does this
say that we should all switch to the ancient Babylonian (base sixty)
system, where 1/3 can be represented exactly as <00>.<20>? I don't think
so.

The point is, that any number can be represented to any level of
precision (short of exact) in any radix.  No radix can represent all
numbers exactly; Georg Cantor proved that a long time ago.

I concede that there is a problem in dealing with bankers and other
people who expect dollars and cents to come out even.  But a dollar
amount isn't a floating point number at all: it's an integer number of
cents!  In COBOL and PL/1, there are facilities to deal with the idea
that an integer might have a "decimal point" in its displayed
representation.  In most other languages, you just have to remember that
a variable contains an amount in cents and convert it before
displaying. It's not that tough.  Really it isn't.

The floating point implementations that "don't have this problem" use
"fuzzy comparisons".  What this means is that if the difference between
two numbers is less than some arbitrary constant times the smaller one,
they are considered equal.  This keeps the bankers happy, but drives the
engineers up a wall; there's an implicit loss of (real) precision to
gain the (perceived) accuracy.

Enough said.  Just a one sentence summary:

COMPARING TWO FLOATING POINT NUMBERS FOR EXACT EQUALITY IS NEARLY ALWAYS
A MISTAKE, WHATEVER BASE THE MACHINE USES.

/k**2

20-Feb-84 09:55:03-MST,1166;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 20 Feb 84 09:54:57-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  18 Feb 84 5:19 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  18 Feb 84 5:06 EST
Date: 18 February 1984 05:06 EST
From: Jerry E. Pournelle <POURNE@mit-mc>
Subject:  Turbo Pascal--first impressions
To: Kenny%PCO@cisl-service-multics
cc: INFO-CPM@mit-mc
In-reply-to: Msg of Fri 17 Feb 84 18:05 MST from Kevin Kenny <Kenny%his-phoenix-multics.arpa at BRL.ARPA>

1. My mistake: I repeated something I was told.
2. Turbo is going to DOCUMENT the fact that frac of a floating
point number is close to ONE, not close to ZERO; apparently this
representation scheme is in use in other machines, and they're
staying compatible.
3. Computer science is wonderful, but I'm glad you don't do my
taxes or take care of my bank account.
4. I don't much care about the subjects of your flame, but I do
care about ease of use and just getting the job done; and I
don't think I want to train MBA candidates to think about
numerical representations, merely to be able to use the
machines.

20-Feb-84 09:55:34-MST,1442;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 20 Feb 84 09:55:28-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  18 Feb 84 15:05 EST
Received: From Mit-Xx.ARPA by BRL via smtp;  18 Feb 84 14:58 EST
Date: Sat 18 Feb 84 14:58:35-EST
From: Larry Seiler <Seiler@MIT-XX.ARPA>
Subject: Floating point money
To: POURNE@MIT-MC.ARPA
cc: Seiler@MIT-XX.ARPA, Info-CPM@BRL.ARPA

FLoating point numbers are the wrong thing to use in what is
essentially an integral application (integral numbers of pennies).
Although there are ways around this - such as rounding values to 
the nearest penny before comparing them.  If you want ease of use
for those MBA's (a worthy goal, certainly), then print out numbers
and let them type numbers with two digits past the decimal point, 
but store all numbers internally as numbers of pennies (the MBA's 
won't be writing programs, just using them).  And keep those MBA's 
away from Multiplan.  While I love Multiplan dearly, don't expect 
it to work any better than Turbo Pascal on floating point comparisons.  
In fact, my copy of Multiplan (for the VT180) can't even round zero 
to two decimal places and get something that is equal to zero (details
on request).  Number representation is a tricky problem, I'm sorry to say,
and I'd hate to use a tax program written by someone who couldn't see
what the problem is.
	Larry
-------
20-Feb-84 09:56:26-MST,883;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 20 Feb 84 09:56:22-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  18 Feb 84 21:26 EST
Received: From Parc-Maxc.ARPA by BRL via smtp;  18 Feb 84 21:15 EST
From: DGILBERT.ES@PARC-MAXC.ARPA
Date: 18 Feb 84 17:55:43 PST
Subject: WHERE IS DUPUSR?
To: INFO-CPM@BRL.ARPA


Sorry for the large distribution, but I can't successfully send
this message to BURTON@UCB-VAX.ARPA directly.

In answer to your question.....
================================================
where is this wonderful DUPUSR program located?

tnx.
================================================

Well,

Just about any fairly well stocked RCPM system will have DUPUSR.
I downloaded mine from 

	Pete Mack
	Simi Valley RCPM
	805 - 527 - 2219

	Was on drive F1:  DUPUSR21.AQM

Doug.
20-Feb-84 09:56:39-MST,1205;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 20 Feb 84 09:56:34-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  18 Feb 84 23:03 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  18 Feb 84 22:49 EST
Date: Sat 18 Feb 84 22:50:48-EST
From: Mark Becker <CENT.MBECK%MIT-OZ@MIT-MC.ARPA>
Subject: Re: In support...
To: Pourne@mit-mc
cc: Seiler@MIT-XX.ARPA, Info-CPM@BRL.ARPA
In-Reply-To: Message from "Larry Seiler <Seiler@MIT-XX.ARPA>" of Sat 18 Feb 84 16:39:08-EST

     Oh brother...

     Jerry, I was able to duplicate the silly bug in Turbo.  And IT IS
a bug - It DOES NOT do what the book says it ought to do, despite what
all the mathematicians say.

     On the other hand, just for kicks I tried defining my own frac
function and THAT worked per the manual description.

     What I used was the expansion they give in the book for frac on
page 131.  What a pain - why didn't Borland do it that way to begin
with?

     I wonder what Borland's update policy is?  I remember asking them
about that when I ordered the compiler.  Never did get a reply.

     Well, as they say, caveat emptor...

					Mark
-------

20-Feb-84 10:18:47-MST,1507;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 20 Feb 84 10:18:42-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  20 Feb 84 11:56 EST
Received: From Ut-Ngp.ARPA by BRL via smtp;  19 Feb 84 14:44 EST
From: mknox@ut-ngp.ARPA
Posted-Date: Sun, 19 Feb 84 13:36:43 CST
Message-Id: <8402191946.AA21195@ut-ngp.ARPA>
Received: by ut-ngp.ARPA (4.22/3.14)
	id AA21195; Sun, 19 Feb 84 13:46:13 cst
Date: Sun, 19 Feb 84 13:36:43 CST
To: info-cpm@brl.ARPA
Subject: SELDSK bug in CP/M-86


I just encountered a rather interesting bug in the IBM-PC BIOS implementation
of CP/M-86 (found it the hard way, of course).

   Perform a SELDSK BIOS call (BIOS call number 9) to a disk (it doesn't
   matter what one), specifying that it is a 'new disk'.  It will work
   correctly.

   Without doing any disk READ or WRITE functions, now do another SELDSK
   call for the same disk (again specifying that it is a 'new disk').
   The DISK parameter block returned will UNCONDITIONALLY specify that the
   disk is SINGLE DENSITY!!!

-----

Why would anyone do two disk selects in a row to the same drive?  One case
is an application program that selects a disk upon startup, and is then
instructed by the user to 'log in a new diskette in that drive'.  Since
the density and allocation map may have changed a fresh SELDSK is necessary.

Curiously, any read/write between the SELDSK function fixes the problem.
Other BIOS calls do not.  

20-Feb-84 10:22:22-MST,1052;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 20 Feb 84 10:22:17-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  20 Feb 84 11:56 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  20 Feb 84 3:33 EST
Date: 20 February 1984 03:33 EST
From: Jerry E. Pournelle <POURNE@mit-mc>
Subject:  In support...
To: CENT.MBECK%mit-oz@BRL.ARPA
cc: Seiler@mit-xx, Info-CPM@brl
In-reply-to: Msg of Sat 18 Feb 84 22:50:48-EST from Mark Becker <CENT.MBECK%MIT-OZ at MIT-MC.ARPA>

It's still a prety good compiler (and they are rescinding their
"extra hundred" for unlimit ed license so the price is right.)
Try writing Borland, ATTN: PHILLIPPE KAHN, describe what you
said to me, and put CC:J. E. Pournelle BYTE on the letter (and
do send me a cc).
	I suspect they will (1) tellyou about update policies,
and (2) at least discuss the "feature" (bug?) with youy.

Then tell me what happened, because I get conflicting stories,
and I am tired of having my jugular chewed over this issue.

jep

20-Feb-84 10:22:36-MST,655;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 20 Feb 84 10:22:33-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  20 Feb 84 11:56 EST
Received: From Usc-Isid.ARPA by BRL via smtp;  19 Feb 84 20:04 EST
Date: 19 Feb 1984 17:00-PST
Sender: ABN.ISCAMS@usc-isid
Subject: Re: WHERE IS DUPUSR?
From: ABN.ISCAMS@usc-isid
To: DGILBERT.ES@parc-maxc
Cc: INFO-CPM@brl
Message-ID: <[USC-ISID]19-Feb-84 17:00:56.ABN.ISCAMS>
In-Reply-To: The message of 18 Feb 84 17:55:43 PST from DGILBERT.ES@PARC-MAXC.ARPA

Also via FTP from SIMTEL20 MICRO:<CPM.DIRUTL>DUPUSR2.ASM.1

David Kirschbaum
Toad Hall
20-Feb-84 11:03:25-MST,1819;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 20 Feb 84 11:03:17-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  20 Feb 84 11:56 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  20 Feb 84 8:16 EST
Received: from HIS-PHOENIX-MULTICS.ARPA by CISL-SERVICE-MULTICS.ARPA dial; 20-Feb-1984 07:52:45-est
Date:  Sat, 18 Feb 84 14:11 MST
From:  Kevin Kenny <Kenny%his-phoenix-multics.arpa@BRL.ARPA>
Subject:  Re: Turbo Pascal--first impressions
Reply-To:  Kenny%PCO@CISL-SERVICE-MULTICS.ARPA
To:  "Jerry E. Pournelle" <POURNE@MIT-MC.ARPA>
cc:  INFO-CPM@MIT-MC.ARPA
In-Reply-To:  Message of 18 Feb 84 03:06 MST from "Jerry E. Pournelle"
Message-ID:  <840218211139.394998@HIS-PHOENIX-MULTICS.ARPA>

My apologies for flaming; my last message was written fairly late on a
very bad day.  I, too, am primarily interested in getting the job done,
which involves selecting the right tool to do it.

For doing taxes or balancing bank accounts I'd use scaled fixed-point
arithmetic, which gets the pennies right, and not worry about whether
it's decimal or binary internally.  Funny, do you suppose that's why
COBOL was designed that way?

For engineering work, I want floating point sometimes (although the more
you use it, the less you trust it), and (by preference, not necessity)
binary arithmetic.  On nearly all machines, binary is faster; the
analysis of computation errors is easier, too.

For systems programming, I don't give a damn, since it's non-numeric
anyway.

A language trying to serve every application's needs can't do them all
right without falling into the trap of gigantism (_vide_ PL\1).  I think
Turbo has made the right decision, though I recognize that I'm
personally biased toward engineering and away from finance.

20-Feb-84 11:04:58-MST,810;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 20 Feb 84 11:04:54-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  20 Feb 84 11:57 EST
Received: From Utexas-20.ARPA by BRL via smtp;  20 Feb 84 10:43 EST
Date: Mon 20 Feb 84 09:44:33-CST
From: Aaron Temin <CS.Temin@UTEXAS-20.ARPA>
Subject: dysan head alignment program/disk
To: info-cpm@BRL.ARPA

I recall there being a program in the CPM directories from Dysan that is
reputed to aid in aligning disk drive heads.  I FTP'ed to Simtel-20, but
it was being very uncooperative about allowing me to peruse the
directories.  Could someone give me a full pathname to the file (I think
its root name is DDD)?  Also, has anyone actually used the program
successfully? 

Thanks,
-aaron
-------
21-Feb-84 09:41:05-MST,1281;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 21 Feb 84 09:40:55-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  20 Feb 84 18:37 EST
Received: From Usc-Isid.ARPA by BRL via smtp;  20 Feb 84 18:26 EST
Date: 20 Feb 1984 13:47-PST
Sender: ABN.ISCAMS@usc-isid
Subject: Re: dysan head alignment program/disk
From: ABN.ISCAMS@usc-isid
To: CS.Temin@utexas-20
Cc: info-cpm@brl
Message-ID: <[USC-ISID]20-Feb-84 13:47:26.ABN.ISCAMS>
In-Reply-To: The message of Mon 20 Feb 84 09:44:33-CST from Aaron Temin <CS.Temin@UTEXAS-20.ARPA>

Aaron (et al)
Pathname to the Dysan DDD program for disk drive head alignment:

(FTP from SIMTEL20, ANONYMOUS login, of course)

MICRO:<CPM.DSKUTL>DDD.ASM.1
                  DDD.DOC.1
                  DDD1.ASM.1

Nope, haven't used it myself (don't have the special Dysan disk).

Incidentally, if you want to see a directory (a SINGLE directory),
DIR MICRO:<CPM.directoryname><ESC><ESC> works pretty good -- IF you know
the directory name.  Else...you gotta download (or set up the FTP transfer
to 7 bit ASCII so you can send it to TTY:) MICRO:<CPM>CPM.CRCLST.nn

You can get the latest CPM.CRCLST by DIR MICRO:<CPM><ESC><ESC>.

Regards,
David Kirschbaum
Toad Hall
21-Feb-84 09:41:18-MST,1301;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 21 Feb 84 09:41:10-MST
Received: From Sri-Kl.ARPA by AMSAA via smtp;  20 Feb 84 21:46 EST
Date: 20 Feb 1984 18:45-PST
Sender: BILLW@sri-kl
Subject:  Re:  dysan head alignment program/disk
From: BILLW@sri-kl
To: towson@amsaa
Cc: ABN.ISCAMS@usc-isid, info-cpm@amsaa
Message-ID: <[SRI-KL]20-Feb-84 18:45:05.BILLW>
In-Reply-To: The message of     Mon, 20 Feb 84 21:17:12 EST from     David Towson (CSD) <towson@amsaa>

Yes, it depends on the FTP user program.  The TOPS20 ftp server
defaults unspecified parts of the filename to *, so just a
DIR FILENAME will  actually find FILENAME.*.  By the way, the
tops20 filename format is <directory>filename.extension.version,
its only a sometime used cpm convention that the extension contain
the program version number. directory, filename, and extension can
all be up to 39 characters long, and version is a number less than
some large decimal number.  The tops20 FTP code also contains a
check so that an wildcard directorys cannot be used (presumably,
this is to prevent people from using large amounts of CPU time
doing a directory of the entire file system).  Perhaps this
restriction should be removed from the SIMTEL system ?

BillW
21-Feb-84 09:41:26-MST,696;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 21 Feb 84 09:41:22-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  20 Feb 84 22:18 EST
Received: From Sri-Kl.ARPA by BRL via smtp;  20 Feb 84 21:50 EST
Date: 20 Feb 1984 18:47-PST
Sender: BILLW@sri-kl
From: William "Chops" Westfield <BillW@sri-kl>
To: info-micro@brl, info-cpm@brl
Message-ID: <[SRI-KL]20-Feb-84 18:47:53.BILLW>

SRI-UNIX, which is the gateway to usenet for INFO-MICRO and
INFO-CPM (amoung other mailing lists), has a broken IMP11
interface, and so no net.micro* netnews will be gatewayed
to the arpanet until we manage to find spare parts someplace...

BillW
21-Feb-84 09:42:31-MST,1067;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 21 Feb 84 09:42:25-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  21 Feb 84 8:31 EST
Received: From Dca-Ems.ARPA by BRL via smtp;  21 Feb 84 8:05 EST
Date: 21 Feb 1984  7:57:50 EST (Tuesday)
From: Maj Bower (HQ USEUCOM) <bower@dca-ems>
Subject: disk drive/controller problem
To: info-cpm@brl
Cc: byard@dca-ems

   Has anyone successfully interfaced the Compu/time UFDC-1
controller (which may be the same as QT Systems) with the
Siemens Fdd-221-5 80 track double-sided drive?  I have two
such drives which work with the Versafloppy II and Jade
Double-D, but will do NOTHING on the UFDC-1.  Various
things such as adjusting terminating resistor packs have
had no effect.
   The only difference I have been able to find is that
the UFDC-1 uses a special data seperator chip where
others use op-amp based designs.  Losing the use of
a 784K drive on my portable system is painful.
   Can anyone help?

					Hal Bower
					Bower at DCA-EMS

21-Feb-84 09:43:29-MST,660;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 21 Feb 84 09:43:25-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  21 Feb 84 8:54 EST
Date:     Tue, 21 Feb 84 8:31:05 EST
From:     Keith Petersen <w8sdz@brl>
To:       Aaron Temin <CS.Temin@utexas-20.arpa>
cc:       Info-Cpm@brl
Subject:  Re:  dysan head alignment program/disk

Try MICRO:<CPM.DSKUTL> as the directory on SIMTEL20.  You'll find
the original generic DDD.ASM and a new one DDD1.ASM which I believe
is for a CCS disk controller.  You'll find DDDTAR.LBR on TCBBS
Dearborn, MI (313) 846-6127, which is for the Tarbel controller.
21-Feb-84 09:43:34-MST,921;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 21 Feb 84 09:43:28-MST
Date:     Mon, 20 Feb 84 21:17:12 EST
From:     David Towson (CSD) <towson@amsaa>
To:       ABN.ISCAMS@usc-isid
cc:       info-cpm@amsaa
Subject:  Re:  dysan head alignment program/disk

David - A couple things in your note concerning the whereabouts of the Dysan
DDD program caught my eye:  What are the escapes in the FTP sequences for ?
Our UNIX FTP doesn't use them.  Our syntax is:

     ftp "micro:<cpm.dirname>filename" local_filename

The quotes are there to keep UNIX happy, since the < and > characters are
special in UNIX.  Second, I don't think you need to append the version number
to the filename (as in filename.nn).  I have never been refused by a TOPS-20
system, and I have never used the version number.  Have you had difficulties
if you didn't use it ?


Dave

21-Feb-84 09:44:00-MST,682;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 21 Feb 84 09:43:56-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  21 Feb 84 9:14 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  21 Feb 84 8:51 EST
Date: 21 February 1984 08:52-EST
From: Keith Petersen <W8SDZ@mit-mc>
Subject:  SIMTEL20 CP/M directory list
To: EJS@mit-mc
cc: Info-Cpm@brl
In-reply-to: Msg of 20 Feb 1984 14:15-EST from Eric J. Swenson <EJS>

A complete list of all directories containg CP/M files on SIMTEL20 is
available on MIT-MC as ARMTE;CPM DIRLST.  This is a copy of
MICRO:<CPM>CPM.CRCLST from SIMTEL20 and is updated frequently.
--Keith

21-Feb-84 18:10:36-MST,768;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 21 Feb 84 18:10:31-MST
Date:     Tue, 21 Feb 84 19:56:40 EST
From:     David Towson (CSD) <towson@amsaa>
To:       Earnie Boyd DRSTE-CM-F 4377 <eboyd@apg-1>
cc:       info-cpm@amsaa
Subject:  Quotes around filenames in FTP command lines.

Ernie - Thanks for your note saying that quotes are not needed around filenames
in FTP command lines sent from UNIX unless there is a SPACE in the filename.
Sure enough; I tried it without the quotes and it worked fine on Simtel20.
You are also right about where I got into the habit of using quotes.  I got it
from FTPing from Mit-mc, which does have two-part filenames with the parts
separated by a space.


Dave

22-Feb-84 10:24:03-MST,1117;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 22 Feb 84 10:23:43-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  21 Feb 84 21:12 EST
Received: From Sri-Sprm.ARPA by BRL via smtp;  21 Feb 84 21:07 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 20 Feb 84 0:10-PST
Date: 19 Feb 84 6:03:12-PST (Sun)
To: info-cpm@brl
From: decvax!decwrl!lipman@ucb-vax
Subject: id AA04376; Sun, 19 Feb 84 06:02:59 pst
Article-I.D.: decwrl.5690

Message-Id: <8402191402.AA04376@decwrl.uucp>
Date: Sunday, 19 Feb 1984 06:05:21-PST
From: dosadi::binder  (Wanted:  A good five-cent nickel)
To: net.micro.apple, net.micro.cpm, net.micro, applenet, cpmnet, micronet
Subject: Want KERMIT

Is anyone out there willing to provide copies of KERMIT-65
for the Apple ][ and KERMIT-80 for Apple ][ CP/M on disk?

I will happily pay your costs for the disks and mailing.

I already have the documentation.

Please contact me directly by netmail or telephone.  Thanks.

- Dick Binder
decvax!decwrl!rhea!dosadi!binder
(617) 486-6363 (0815-1700 weekdays)
22-Feb-84 10:24:07-MST,1634;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 22 Feb 84 10:23:49-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  22 Feb 84 1:21 EST
Received: From Sri-Sprm.ARPA by BRL via smtp;  22 Feb 84 1:11 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 17 Feb 84 4:19-PST
Date: 15 Feb 84 12:44:40-PST (Wed)
To: info-cpm@brl
From: decvax!genrad!rick@ucb-vax
Subject: cpm 2.2 bios
Article-I.D.: genrad.3855

	Has anyone every successfully modified their bios to handle xon/xoff
protocol for the console in a non-interrupt polled system.  This would 
probably require some sort of buffer arrangement, but characters would only
be noticed if some program or the ccp was polling the status port.  I am also
interested in handling a terminal (vt100) where the special function keys
send out three characters one after the other.  This is particularly nasty
when using them for an editor as characters are often lost.  right now, i
have my cns$ot routine sending out 10 nulls when it detects a line feed
so that the terminal has time to scroll. ( i have another terminal which
also requires this because of the xon/xoff problem).  I have an S-100
system built with assorted boards (including Ithaca Audio z80 board and Jade
Double D Disk Controller.  Am I going to have to add an interrupt controller
to resolve the above mentioned problems?  I forgot to mention that this is
for cp/m version 2.2

	I would very much appreciate any information that anyone has.
				Thank you,

				Rick Frerichs
		uucp:		decvax!genrad!rick
		tel:		617-779-2811 x6435
22-Feb-84 10:24:33-MST,1515;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 22 Feb 84 10:24:08-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  22 Feb 84 5:30 EST
Received: From Sri-Sprm.ARPA by BRL via smtp;  22 Feb 84 5:23 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 22 Feb 84 0:25-PST
Date: 20 Feb 84 7:05:11-PST (Mon)
To: info-cpm@brl
From: harpo!ulysses!burl!clyde!akgua!mcnc!ecsvax!emigh@ucb-vax
Subject: Re: WordStar with ZCPR2
Article-I.D.: ecsvax.2034
In-Reply-To: Article sri-arpa.16735

[]

  There are two other ways to fix this:

1)  WSUFIX5.ASM:  This is a patch to WS.COM and WSOVLY1.OVR that will have
    WordStar search a default user area for COM and OVR files.  Therefore,
    you need only one copy of the WS files (thereby saving you directory
    entries).

2)  SUPUSER.COM:  This program resides just below the BDOS and has a list
    of files and where (drive/user) they are to be found.  The program
    must be initialized for a particular set, and for many programs it
    can be integrated into the COM file (not WordStar, however).

For WordStar, I prefer to use WSUFIX5, since it merely changes the user
area, and does not defeat the drive searching feature of WordStar (look on
default, then on A: (or wherever)).  I have several copies of WS.COM in
my DU areas, each configured for a different application.  I use SUPUSER
for most other programs with overlays, etc.

--Ted Emigh-- decvax!mcnc!ecsvax!emigh
22-Feb-84 10:24:39-MST,664;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 22 Feb 84 10:24:24-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  22 Feb 84 5:30 EST
Received: From Sri-Sprm.ARPA by BRL via smtp;  22 Feb 84 5:27 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 22 Feb 84 0:38-PST
Date: 20 Feb 84 7:53:43-PST (Mon)
To: info-cpm@brl
From: harpo!ulysses!burl!clyde!akgua!mcnc!ecsvax!emigh@ucb-vax
Subject: Re: WordStar with ZCPR2
Article-I.D.: ecsvax.2036
In-Reply-To: Article ecsvax.2034 sri-arpa.16735

[]

  Please replace all SUPUSER with SETDRU.  Sorry.

--Ted Emigh-- decvax!mcnc!ecsvax!emigh
22-Feb-84 10:24:53-MST,1057;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 22 Feb 84 10:24:33-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  22 Feb 84 6:06 EST
Received: From Sri-Sprm.ARPA by BRL via smtp;  22 Feb 84 5:59 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 18 Feb 84 5:44-PST
Date: 16 Feb 84 13:54:51-PST (Thu)
To: info-cpm@brl
From: ihnp4!ihuxf!vej@ucb-vax
Subject: Blow out deal on Verbatim head cleaning kits
Article-I.D.: ihuxf.2027

I have a few brand new Verbatim 8 inch disk head cleaning kits and
am willing to let them go at ANY reasonable price.
These babys were selling for $11.95 from Verbatim.
I bought these with a group purchase of some equipment
and I am willing to make a deal to clear them out.
First come first serve so call or write soon.
NO REASONABLE OFFER REFUSED!!


	work phone: 312-979-2890
	home phone: 312-961-1207
	
	or send mail to ihuxf!vej	

				Dwight Yackley
				office 6L313 x2890
				AT&T Bell Labratories
				Naperville, Illinois
				
22-Feb-84 10:25:03-MST,1337;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 22 Feb 84 10:24:46-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  22 Feb 84 6:07 EST
Received: From Sri-Sprm.ARPA by BRL via smtp;  22 Feb 84 6:01 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 18 Feb 84 5:57-PST
Date: 16 Feb 84 7:05:03-PST (Thu)
To: info-cpm@brl
From: harpo!ulysses!burl!clyde!akgua!itm!danny@ucb-vax
Subject: Need info on uc.c transfer stuff
Article-I.D.: itm.1055

[What brings you here?]  <-- Virtual Line.

    Well "Push has come to shove", "The time is now", and
"Jean Kirkpatrick is nobody's baby."

    Anyway, I now have great need to transfer [stdout/file] to
(specifically) a Xerox 820 II (which runs CP/[yuk]M) printer.

    Seemingly, I have 1/2 of the interface: uc.c which was
posted/mailed about 2 weeks ago.  Well, I didn't receive the
man page, or any other documentation with it.  So:

        *Anything* *anyone* has will be appreciated.  Like,
        what do I need on the CP/M side? UMODEM? Naked
        CP/M?  Any experiences, opinions, or sources would
        be appreciated.

    (From the heart) Thanks in advance...

                                Expectingly,

                                Danny
                    akgua!itm!danny
22-Feb-84 10:25:24-MST,1384;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 22 Feb 84 10:25:03-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  22 Feb 84 6:20 EST
Received: From Sri-Sprm.ARPA by BRL via smtp;  22 Feb 84 6:09 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 18 Feb 84 10:57-PST
Date: 17 Feb 84 6:23:31-PST (Fri)
To: info-cpm@brl
From: ihnp4!ihlts!w9skd@ucb-vax
Subject: RBBS Message Transfer
Article-I.D.: ihlts.366

  I have heard rumors of CP/M RBBS late nite, automatic message exchange
networks (like UUCP?).  I am interested in using this technique to exchange
mail between my Packet Radio RBBS and other packet LAN's.  If anyone has
any information on protocols, people doing this, please let me know.

If such systems don't exist, I have a draft for an inter-lan message
protocol and would be interested in sharing my ideas.

  Comment in passing.  I have modified BYE.ASM into several versions.
One allows access from a normal VHF-FM Amateur RTTY station, and the other
from a Amateur Packet Radio station though my TNC.  I am currently using
RBBS.BAS for the bulletin board, but am in the process of writing a
system that is specially tailored to Amateur Packet Radio (using ideas
stolen from Frank Wancho's RBBS4.C).

-- 
+++++
		F. R. "Dick" George
		ihnp4!ihlts!w9skd
		312/979-4390
		
22-Feb-84 10:25:33-MST,941;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 22 Feb 84 10:25:21-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  22 Feb 84 6:32 EST
Received: From Sri-Sprm.ARPA by BRL via smtp;  22 Feb 84 6:21 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 19 Feb 84 6:39-PST
Date: 18 Feb 84 6:31:03-PST (Sat)
To: info-cpm@brl
From: decvax!decwrl!lipman@ucb-vax
Subject: id AA26208; Sat, 18 Feb 84 06:30:53 pst
Article-I.D.: decwrl.5681

Message-Id: <8402181430.AA26208@decwrl.uucp>
Date: Saturday, 18 Feb 1984 06:31:31-PST
From: dosadi::binder  (Wanted:  A good five-cent nickel)
To: net.micro.cpm, cpmnet
Subject: Apple CP/M question

Does anybody know how I can tell my Apple Microsoft CP/M V2.23 that the
disks connected are 40-track drives?  I'd like to get that extra 20KB
of storage...

Thanks in advance.

- Dick Binder
decvax!decwrl!rhea!dosadi!binder
22-Feb-84 10:25:55-MST,5223;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 22 Feb 84 10:25:34-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  22 Feb 84 7:30 EST
Received: From Sri-Sprm.ARPA by BRL via smtp;  22 Feb 84 7:23 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 22 Feb 84 3:25-PST
Date: 21 Feb 84 3:25:06-PST (Tue)
To: info-cpm@brl
From: decvax!vortex!lauren@ucb-vax
Subject: Cure for Vadic Triple Modem Problem
Article-I.D.: vortex.262

Reposting due to failure of SRI-UNIX gateway...

---

So bunky, you say you got yourself a Racal-Vadic triple modem
(3451-series) and you have some problems with it?  You say that sometimes
in auto-answer mode it seems to hang offhook, making it impossible for any 
new calls to arrive?  You say that when this happens it refuses to respond
to DTR and only resets if you cycle the power or fiddle with the mode
toggle switch (if you have one, that is)?  Is that what's bothering
you, bunky?

WELLLLL!  Lift up your head and greet the sun, 'cause a solution
does exist -- and it doesn't even involve hydrochloric acid or 
jackhammers!  

Seriously, though, many persons have reported problems with triple modems
getting into a strange wedged condition from which it is difficult
to escape.  Both manual dial and autodial triples have shown this 
behavior, which is characterized by the modem being offhook, sending
a 212 carrier, and having both the HS and DSR lights lit.  Only cycling
the power or performing a software reset (by flipping the toggle switch
between auto and manual on the autodial modems) will clear this condition;
the modem is oblivious to DTR.  After having this occur repeatedly on the
main Vortex dialup line, I started harassing the engineers up at
Racal.  Actually, they were quite helpful, once they realized that I knew
what I was talking about and hadn't plugged the RJ-11C phone plug into
an AC wall outlet!

After talking with three different engineers and having them duplicate
the problem on their test benches, we arrived at the cause of the problem
and a (simple) solution.  The problem is caused by a "hole" in the triple
modem protocol select algorithm.  Under certain random timing conditions,
the modem may be "fooled" into entering a pseudo-originate mode during 
its answer-mode operations.  The exact reasons are too complex to go
into here, but the cure is straightforward:

Inside the modem, option dip switch A1 is described by the manual
as:

"Attended/Unattended Disconnect -- Set to Attended [ON] for Auto Dial modems.
(Unattended setting relates to manual originate operation only.)"

DON'T YOU BELIEVE IT!  This switch also affects the handling of DTR
during answer mode processing.  The "normal" setting of this option
(as set by the "standard-options" switch A6) is ON (Attended).
This is WRONG for almost all operations.  For both auto-dial and
non-autodial triple modems, this option should normally be
set to OFF (Unattended).  The only side effect of this is that if
you attempt to use the modem in a MANUAL originate mode, you will
probably have to supply DTR at the RS232 interface (big deal!)
If you leave A1 OFF, the answer mode wedging problem should vanish!
Auto-dial operations on auto-dial modems should work as always.

NOTE: If your triple has switch A6 OFF, then "standard-options" mode
is ENABLED and the remaining A and B switches are ignored.  In order
to change the state of A1 to OFF, you must also turn switch A6 ON
to disable "standard-options" and make sure that all other switches are
set appropriately.

I recommend the following settings (some of these are NOT the
default settings):

A1  --  OFF  (Unattended -- fixes the answer wedge problem)
A2  --  OFF  (Do NOT respond to remote test) [do you want everyone in 
	     the universe "testing" your modem for you?]
A3  --  ON   (10 bit chars -- this is normal)
A4  --  ON   103 operation enabled
A5  --  OFF  (10 bit chars -- this is normal)
A6  --  ON   Disable standard-options (enables all other switches)
A7  --  ON   Auto-disconnect on loss of carrier enabled

B1  --  OFF  Local digital loopback select (ignored when not testing)
B2  --  OFF  DTR controlled from RS232 interface
B3  --  OFF  Originate and Answer modes allowed
B4  --  OFF  1204 bps speed (this is normal)
B5  --  ON   Auto-disconnect/Abort timer enabled
B6  --  OFF  Asynchronous operation
B7  --  ON   DSR off in test (ignored when not testing)

In addition, I recommend the following two jumper changes on the
BOTTOM pc board:

Insert jumper "r"  -- enable data rate indicator on RS232 pin 12
Remove jumper "ag" -- do not tie carrier detect high (RS232 pin 8)

------

The "wedged" condition mentioned above, being related to a rather
random timing window, is more likely to have been seen on modems
that have a high volume of calls than on low volume incoming lines.
However, it occurs frequently enough that I recommend the option
change for all triple modems being used for incoming calls.

Be sure to let me know if you have any questions about or problems with
this info.  I hope it's of some use, bunky...

--Lauren--
22-Feb-84 10:26:07-MST,1685;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 22 Feb 84 10:26:00-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  22 Feb 84 7:31 EST
Received: From Sri-Sprm.ARPA by BRL via smtp;  22 Feb 84 7:25 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 22 Feb 84 4:13-PST
Date: 21 Feb 84 9:00:44-PST (Tue)
To: info-cpm@brl
From: ihnp4!ihuxx!ignatz@ucb-vax
Subject: Re: Turbo Pascal
Article-I.D.: ihuxx.677
In-Reply-To: Article <16676@sri-arpa.UUCP>

	Read Jerry's comments about Turbo in Feb. Byte.  By the way, I disagree
	with his gripes concerning Borland's policy of charging extra $100 for
	unlimited object code distribution.  Why didn't Jerry complain about
	Sorcim not letting people distribute freely the PRUN.COM file (i.e. the
	p-code interpreter that comes with Pascal/M)?  In a sense, this would
	equivalent, as linked object code is made in large part of library
	procedures.  Now, quite possibly the the general trend is toward automatic
	licensing of compiler's output.  I only think that Jerry's flames were
	exagerated.
	--Ed Howorka.

Excuse me, but I *thoroughly* agree with Jerry's complaints about the
$100 fee.  A compiler or interpreter is a tool.  If I can't use it as
one without forking over extra money to the providers of the tool,
it's totuse such a tool for production work.  (Never mind that I wouldn't
produce a marketable product in PASCAL in the first place...) And often
such a charge is added on a per-unit distribution basis!  I refuse
to encourage practices in any way whatsoever, and I encourage others
to do likewise.

				Dave Ihnat
				ihuxx!ignatz
22-Feb-84 10:31:54-MST,1691;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 22 Feb 84 10:31:40-MST
Received: From Rochester.ARPA by AMSAA via smtp;  22 Feb 84 11:25 EST
Received: by sen.rochester (3.327.3N) id AA01174; 22 Feb 84 11:24:45 EST (Wed)
Received: by cay.Rochester (3.327.3N+) id AA00479; 22 Feb 84 11:22:21 EST (Wed)
Message-Id: <8402221624.1174@sen.rochester>
Date: 22 Feb 84 11:24:45 EST (Wed)
From: Mike Ciaraldi <ciaraldi@Rochester.ARPA>
Subject: Uc.c
To: info-cpm@amsaa.ARPA

I have been using umodem.c (version 3.6) for
Unix to CP/M file transfers, and wanted to upgrade to 
uc.c, since it has CRC checksumming.

I fetched it from SIMTEL, and it compiled OK, but when I run
it I immediately get a segmentation fault, before it even
prints the sing-on message (the printf is the FIRST executable
statement!).
I contacted Rick Conn and he said he wrote this for System V.
We are running BSD 4.1c (soon to convert to 4.2).

For comparison, umodem has conditional-compile flags for
JHU (Johns Hopkins), VER7 (Version 7, also good for Berkeley),
and SYS3 (for System III, and V also, I suppose).

Does anyone know how to fix up uc.c? The differences on
umodem have to do with how you tell the system to kill echo,
go to 8-bit transmission, etc. But all these calls are
after the printf, so why don't we even see the sign-on message?
(last-minute thought: maybe the output buffer is not
getting flushed).  

I suppose I could hack up uc.c and put in the same things umodem
has, but if someone else has already done it, I would
appreciate a copy. Also, it should be added to the archives.

Mike Ciaraldi
ciaraldi@rochester
22-Feb-84 11:33:23-MST,1740;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 22 Feb 84 11:33:16-MST
Received: From Brl-Voc.ARPA by AMSAA via smtp;  22 Feb 84 13:16 EST
Date:     Wed, 22 Feb 84 13:01:03 EST
From:     "Ferd Brundick (LTTB)" <fsbrn@brl-voc>
To:       Mike Ciaraldi <ciaraldi@rochester.arpa>
cc:       info-cpm@amsaa.arpa
Subject:  Re:  Uc.c

Haaah,

Out of curiosity, I grabbed a copy of uc.c and tried to compile it
under 4.2 bsd.  So far, so good.  Then I executed it and got the
help screen.  I executed it a second time with the '-z' option and
played around with the menu (I'm a umodem user and have never used
uc before).  Everything worked fine except for the 'd' command.  It
tried to execute the system command 'dir' which we don't have; I
renamed it 'ls -l', recompiled, and now 'd' works the way it should.
I couldn't test the file transfer commands because my micro is at
home (and doesn't work thru the TAC anyway).

The bottom line is that everything looks ok to me.  Did you try a
simple test like this, or were you only attempting file transfers ??

PS.  I also applaud umodem.c for checking for various OS flags, but
I spent my entire lunch break recently trying to get it to compile
under 4.2.  I had to try every flag because there was not an entry for
it.  If there is a help file available -- not how to USE the program,
but how to COMPILE it -- I would appreciate a pointer to it.  If there
isn't, I think one should be written.

                                        dsw, fferd
                                        Fred S. Brundick
                                        USABRL, APG, MD.
                                        <fsbrn@brl-voc>
23-Feb-84 08:08:29-MST,963;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 23 Feb 84 08:08:22-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  22 Feb 84 22:06 EST
Date:     Wed, 22 Feb 84 22:03:13 EST
From:     Bob Bloom (TECOM) <bbloom@brl>
To:       info-cpm@brl
Subject:  A fast(er) W* 3.3 start-up

According to a Robert P. Van Natta in January's "The Software Magazine"
(just received today - but no comment needed on that!) in a article
one can speed up the start-up by ddt patches:
	02b2 - 40 --> 00
	3f1d - 20 --> 00
	411f - A0 --> 00
The first is the old "DEL4" patch point for lenght of logo display.
The other two "will suppress the display of the trade secret notice
and logo respectively"

One should only do this to purchased, legal copiesW*.  ;-)

I've tried it and it seems to work.  Something is still thrown to the
screen but too rapidly to read.  (Good 'nough for gov'ment work.)

-bob bloom
23-Feb-84 08:18:08-MST,1245;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 23 Feb 84 08:17:58-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  23 Feb 84 4:52 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  23 Feb 84 4:47 EST
Date: 23 February 1984 04:47-EST
From: Jerry E. Pournelle <POURNE@mit-mc>
Subject:  Turbo Pascal
To: ihnp4!ihuxx!ignatz@ucb-vax
cc: info-cpm@brl
In-reply-to: Msg of 21 Feb 84 9:00:44-PST (Tue) from ihnp4!ihuxx!ignatz at ucb-vax

1.  Relax.  Borland has dropped the "extra charge" for
licensing fees.
2. I doubt you actually read what I said, since you ask
questions that were answered in the article itself.

3. SORCIM didn't encourage (allow) distribution of PRUN because
they didn't want to support it and all the programs that would
be written in it; and indeed, they have ceased to sell PASCAL/M
entirely, which is a pity, since it was a good teaching
language; but they decline to support it.  I gather there are
some negotiations between Workman and SORCIM that might lead to
Workman becoming a source of Pascal/M; but no details.
	I never heard of a case where SORCIM tried to STOP
anyone from distributing PRUN; but they sure wouldn't explictly
allow it.

23-Feb-84 08:24:58-MST,1784;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 23 Feb 84 08:24:51-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  23 Feb 84 9:58 EST
Received: From Radc-Tops20.ARPA by BRL via smtp;  23 Feb 84 9:46 EST
Date: Thu 23 Feb 84 09:45:23-EST
From: Gern <GUBBINS@RADC-TOPS20.ARPA>
Subject: Mailing List Submit Kickbacks and Control
To: INFO-MICRO@BRL.ARPA, INFO-CPM@BRL.ARPA



As anyone who has sent a message to this (or any) mailing list knows,
bad addresses of persons on the list get kicked back to the sender.
This gives the submitter a bunch of rejected mail from persons he
has never heard of.   There is nothing the maintainer of the list
can do to find the bad addresses, except send a test message thru
and hack off the rejected kickbacks.  Requests for addition to
this list is rather good, and many hosts I have never heard from
(but work okay).  Some sites re-redistribute this list, so that
kickback problems may not be related to this master list, but
several systems deep somewhere.  The first thing I checked into
when I got the mailing list to redistribute was this problem, and
it goes beyond the scope of control of this system as the rejected
messages are sent back to the submitter from the problem site, not
back here first.  Yesterday, I hacked off 2 more problem addresses,
one never gave any trouble before and the other from a new person
that had a stable address.  The point is, unless I submit something
and get the kickbacks, or persons are kind enough to flag me as
to the problem addresses, I have no way to find out the problems.
If someone knows a way to control and/or monitor this, please flag
me.  Thanx

Gern
INFO-HZ100@RADC-TOPS20 Coordinator
-------
-------
23-Feb-84 11:55:10-MST,1288;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 23 Feb 84 11:55:05-MST
Received: From Nrl-Aic.ARPA by AMSAA via smtp;  23 Feb 84 13:38 EST
Date: 23 Feb 1984 13:12-EST
From: Russ Smith <smith@nrl-aic>
Subject: THE modem program
To: info-cpm@amsaa
Message-Id: <84/02/23 1312.533@NRL-AIC>

I was just looking over the most recent simtel20 CPM CRCLST copy and
noticed that the infamous MDM7** series is up to 724! Good grief!!
Is this the ballyhooed (sp?) version that was to replace Irv Hoff's
or is this something else? When were the other versions (briefly) put
on the system? Is there any reason for someone who seldom uses home 
remote file transfer to give up on version 712 or so and update to
724 (or is it 725 by now (726?))? If this isn't the new radically
altered MDM program will one of these soon be?

Pardon the questions but the last reference I remember anyone making to
the net specifically about the MDM stuff mentioned that version 720
would be completely different and better (in some way or other) than
the stuff originally done by half a dozen people, Irv Hoff in
particular. I was rather surprised to see what appeared to be a
continuation rather than a jump in the series.

Russ <Smith@nrl-aic>
23-Feb-84 13:58:16-MST,998;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 23 Feb 84 13:58:11-MST
Date:     Thu, 23 Feb 84 15:32:53 EST
From:     David Towson (CSD) <towson@amsaa>
To:       Russ Smith <smith@nrl-aic>
cc:       info-cpm@amsaa
Subject:  Re:  THE modem program


Russ - The 724 version of MDM was contributed by Irv Hoff.  If you FTP the
file "micro:<cpm.modem7>mdm724.msg" you can read a brief version of the update
history.  No, this is not the promised "super version".  That is being done by
Ron Fowler.  In my opinion, there is no reason for you to switch from MDM712
unless you can benefit from the particular enhancements that have been added
since that version.  These deal mainly with autodial applications, but there is
also a change in the way memory is allocated to receiving buffers.  Some folks
were having trouble with the 16K file-transfer buffer taking too long to be
written to disk, and they needed a smaller buffer.

Dave

23-Feb-84 16:47:26-MST,772;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 23 Feb 84 16:47:22-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  23 Feb 84 18:25 EST
Received: From Brl-Bmd.ARPA by BRL via smtp;  23 Feb 84 18:23 EST
Date:     Thu, 23 Feb 84 18:15:57 EST
From:     Charlie Strom (NYU) <strom@brl-bmd>
To:       hplabs!hao!kpno!amd70!phil@ucb-vax
cc:       INFO-CPM@brl
Subject:  Desoldering techniques

Ypu brought up a pet subject of mine - namely the best technique to
use to remove IC's from pc boards. I have tried a large number of alternatives
and have finally decided that a heated iron with a vacuum source is the
best tool for such purposes, but I'm always open to suggestions and
new ideas. Any comments?

24-Feb-84 08:08:00-MST,717;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 24 Feb 84 08:07:42-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  24 Feb 84 6:06 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  24 Feb 84 5:59 EST
Date: 24 February 1984 05:59-EST
From: Paul R. Grupp <GRUPP@mit-mc>
Subject:  Desoldering techniques
To: strom@brl-bmd
cc: INFO-CPM@mit-mc
In-reply-to: Msg of Thu 23 Feb 84 18:15:57 EST from Charlie Strom (NYU) <strom at brl-bmd>

I've always found it easier to cut the IC leads one at a time, *THEN*
desolder the "stubs".  (You wern't planning on putting it back I hope!)
An even better way is not to buy boards that don't use sockets.

--Paul

24-Feb-84 10:19:45-MST,1253;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 24 Feb 84 10:19:40-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  24 Feb 84 12:02 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  24 Feb 84 11:53 EST
Date: Fri 24 Feb 84 08:43:12-PST
From: Bud Spurgeon <SPURGEON@SUMEX-AIM.ARPA>
Subject: Re: Desoldering techniques
To: GRUPP@MIT-MC.ARPA
cc: strom@BRL-BMD.ARPA, INFO-CPM@MIT-MC.ARPA
In-Reply-To: Message from "Paul R. Grupp <GRUPP@mit-mc>" of Fri 24 Feb 84 02:59:00-PST

I've found that for something you can carry in your toolbox, a hand-held
"solder sucker" used along with a soldering iron works about the best.
Carry along some of the "solder braid" stuff for really hard to unsolder
items, and maybe a higher temperature tip for your soldering iron to
convince the braid to work (the heavier braid really soaks up the heat).

For bench use I've found the vacuum pump based machine, specifically those
models made by Pace to be better (faster,cleaner,leaves re-usable holes
and trace) than anything else.  You must fiddle with this equipment more
though.  It works best only when kept really clean, with clean filters
and tips.  Then it works real well.
		-Bud
-------

24-Feb-84 16:03:09-MST,621;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 24 Feb 84 16:03:03-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  24 Feb 84 17:42 EST
Received: From Parc-Maxc.ARPA by BRL via smtp;  24 Feb 84 17:31 EST
Date: Fri, 24 Feb 84 17:29 EST
From: Slade.wbst@PARC-MAXC.ARPA
Subject: BDS C & DEC VT180
To: info-cpm@brl.arpa
cc: Slade.wbst@PARC-MAXC.ARPA

I am porting a  BDS C program onto a DEC VT180. Could anyone supply the
proper parameters that should be set in the hardware.h file and should
anything be changed in bdscio.h?

Thank you-

Mike Slade

24-Feb-84 18:24:31-MST,657;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 24 Feb 84 18:24:26-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  24 Feb 84 20:04 EST
Received: From Parc-Maxc.ARPA by BRL via smtp;  24 Feb 84 19:56 EST
Date: Fri, 24 Feb 84 16:54 PST
From: MMOON.ES@PARC-MAXC.ARPA
Subject: Re: cpm 2.2 bios
In-reply-to: "decvax!genrad!rick@ucb-vax.ARPA's message of 15 Feb 84
 12:44:40 PST (Wed)"
To: decvax!genrad!rick@ucb-vax.ARPA
cc: info-cpm@brl.ARPA

Message me if you get any ratiional suggestions; L50 can be used to good
effect in xon/xoff mode if the 'frame speaks the same.

		MMoon.es


27-Feb-84 08:16:58-MST,652;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 27 Feb 84 08:16:49-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  26 Feb 84 16:54 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  26 Feb 84 16:48 EST
Date: Sun 26 Feb 84 16:47:32-EST
From: Clifford A. Lasser <CAL%MIT-OZ@MIT-MC.ARPA>
Subject: lost program
To: INFO-CPM%MIT-OZ@MIT-MC.ARPA

I recently managed to loose all my copies of SID.  I originally purchased
SID from Lifeboat, but since that was such a long time ago, they will only
sell me a new copy at the full price.  Is there anything I can do about this?
-Cliff
-------

27-Feb-84 08:17:02-MST,721;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 27 Feb 84 08:16:58-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  26 Feb 84 18:48 EST
Received: From Usc-Isi.ARPA by BRL via smtp;  26 Feb 84 18:42 EST
Date: 26 Feb 1984 15:41-PST
Sender: SCHNUR@usc-isi
Subject: Exon 500
From: SCHNUR@usc-isi
To: info-cpm@brl
Message-ID: <[USC-ISI]26-Feb-84 15:41:42.SCHNUR>

The Division where I work at NRL has just pruchased many Exxon
500 for word processing.  Does any body out htere have one?  Has
any body set them up with Bye and mdm7?  Exxon has not yet
provided us with port maps etc so any help would be of great use.

Joel schnur (6510-NRL) Schnur @isia
27-Feb-84 08:17:10-MST,568;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 27 Feb 84 08:17:06-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  27 Feb 84 4:09 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  27 Feb 84 4:08 EST
Date: 27 February 1984 04:07-EST
From: Frank J. Wancho <FJW@mit-mc>
Subject:  RBBS 4.0 Edit 21 Available
To: INFO-CPM@brl

RBBS421.LBR is temporarily available on MC:FJW;RBBS 421LBR.  The
individual files (and this .LBR) will be available on the SIMTEL20 in
MICRO:<CPM.RBBS4> later today.

--Frank

27-Feb-84 08:31:48-MST,4316;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 27 Feb 84 08:31:32-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  24 Feb 84 22:53 EST
Date:     Fri, 24 Feb 84 22:43:22 EST
From:     Keith Petersen <w8sdz@brl>
To:       Russ Smith <smith@nrl-aic>
cc:       Info-Cpm@brl
Subject:  Re:  MDM724 update

Ron Fowler has not released his program.  It will have a different
name, more features and be easier to configure.

I have uploaded MDM724, the latest version in the MDM7xx series,
to SIMTEL20 (and also temporarily available on MIT-MC in directory
AR100:FJW; ).  You asked what was new... here's the information.
I see no reason to get upset when people update a program to make
it better, if you chose to stay with an older version, that's
your decision.  I like the new features.

---
TOPIC:	MDM724.ASM MODEM PROGRAM

FROM :	IRV HOFF W6FFC

DATE :	17 FEB 84


	NOTE:	This program when assembled is 72 sectors
		long.  Use this figure when merging the
		appropriate overlay file for your computer
		via DDT, etc.  (Most of the overlays were
		written when MDM7xx.COM was only 66 sectors
		and the example included in each says to
		store 66 sectors.)  For MDM724 use:

			B>SAVE 72 MDM724.COM

	NOTE:	M7LIB.COM is a rapid and surprisingly easy
		way to quickly change any entries in the
		phone number library.  See M7LIB.DOC if
		instructions are needed.  M7NM-6.ASM is
		necessary for setting or altering numbers
		for 'SPRINT', 'MCI', etc.
		
	NOTE:	If using the phone number overlay to change
		the phone library numbers, be sure to use:

			     M7NM-6.ASM

		(Previous versions of M7NM will not work with
		this new version, as the phone number library
		now contains 36 numbers (A-Z as usual plus 0-9)
		rather than the 26 in versions prior to MDM722.)

     Most users will not need the lengthy (160k) source code at all.
     Just get MDM724.COM and then check one of the associated over-
     lay programs to obtain the overlay for your particular computer.
     Merge that with MDM724.COM according to the instructions near
     the start of the overlay file, using DDT.COM, etc.  (See above
     note relative to saving 72 sectors.  STAT.COM would then show
     144 records for 18k.)

     The following bytes can be changed easily with DDT, then Save 72

	0DFEH  -  HEXSHOW 00 = do not show hex record count
			  FF = show both hex and decimal count
	0DFFH  -  SAVSIZ  20 = 4k file transfer buffer size
			       (see table below for other options)
	0E00H  -  NUMBLIB (start of telephone number library)

     To change the file transfer buffer size via DDT, change byte 0DFFH:

		10   (hex)   =   16 records   =   2k
		20   (hex)   =   32 records   =   4k
		40   (hex)   =   64 records   =   8K
		60   (hex)   =   96 records   =  12k
		80   (hex)   =  128 records   =  16k

				- Irv Hoff
RECENT CHANGES:
--------------

(READ THE UPDATE HISTORY IN MDM723.ASM FOR MORE DETAILED INFORMATION)

MDM724 - added 10 function keys for auto-typing preselected messages

MDM723 - alphabetizes the phone library vertically for:
         'CAL' - used with auto-dial modems including PMMI
	 'NUM' - used with manually-dialed modems

MDM722 - phone number library now has 36 entries rather than 26 (has
	 A-Z as usual plus 0-9).  Better supports single-digit result
	 codes for the Anchor Mark XII modem as well as Hayes and USR.

MDM721 - makes it easier to abort an auto-dial call with CTL-X.

MDM720 - changed from BIOS to BDOS call to run the printer.

MDM719 - modest changes, PMMI pulse dialing set faster.

MDM718 - now supports the Anchor Mark XII modem.  Buffer size for ASCII
	 capture set for 16k.  Buffer size for file transfers adjustable
	 from 1 sector to 16k.  (Allows for slow floppy disk systems so
	 XMODEM does not show a timeout error.)

MDM717 - Log-on now works properly on main frames that echo characters
 	 with parity set.

CREDITS:
-------

MDM724 - Sigi Kluger
MDM723 - Irv Hoff with routine developed by Ken Lovett
MDM722 - Bill Brehm with routines developed by Fred Viles
MDM721 - Bill Brehm
MDM720 - Irv Hoff
MDM719 - Keith Petersen
MDM718 - Irv Hoff with routine developed by Fred Viles
MDM717 - Irv Hoff
27-Feb-84 08:31:51-MST,2464;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 27 Feb 84 08:31:38-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  24 Feb 84 22:53 EST
Date:     Fri, 24 Feb 84 22:45:02 EST
From:     Keith Petersen <w8sdz@brl>
To:       Russ Smith <smith@nrl-aic>
cc:       Info-Cpm@brl
Subject:  MDM724 key string info

MDM724 update information

Sigi Kluger, El Paso TX  02-17-84

Being used to a great non-public modem program with a number of
function keys, I decided to add ten function keys to MDM7.  Great
for things you do most, like DIR *.* $U0AD, or XMODEM S, or you
could even save your name in a function key for logon.


1. HOW TO ACCESS (transmit) THE FUNCTION KEYS.

You transmit the contents of a function key by typing first the
INTERCEPT CHARACTER, then a digit 0..9.  The INTERCEPT CHARACTER
is a unique control character which tells MDM7 that a function key
command follows. The INTERCEPT CHARACTER is set to ^A (CONTROL-A).
In the distribution version, the following keys are defined:

^A0	DIR
^A1	DIR *.* $U0AD
^A2	XMODEM S
^A3	XMODEM R
^A4	BYE
^A5	CBBS

(Function keys 2 and 3 have no trailing CR).


2. HOW MUCH ROOM?

A total of 256 bytes are reserved for the function key definition.
Each definition takes up the number of bytes in the string, PLUS 2.
Note that you must not enclose any control characters in the
definitions (CR is allowed, though, and optional).


3. HOW TO CHANGE THE FUNCTION KEYS

In order to not increase the size of MDM7 considerably, I have written
the MDMFNK utility.  MDMFNK.COM is virtually self-explanatory and
covered by its own short DOC file.


4. WHAT WILL NOT WORK

Do not attempt to use DDT to modify the function keys.  Especially, do
not force any control characters into the definitions.  There can only
be three non-printing characters in each definition, the start byte,
an optional CR at the end, and the end byte.


5. DEFINITION FORMAT

This is an example of the definition for function key 1:

DB	1,'THIS IS A FUNCTION KEY',CR,0
	^		^	      ^
	^		^	      stop character
	^		key definition plus CR
	start character

Each key definition string starts with the key number in binary.
The function key processor searches for that number.  Therefore,
those numbers must be unique throughout the key definitions.
EMPTY key definitions are encoded thusly:

DB	9,0		;empty function key #9
27-Feb-84 08:32:07-MST,969;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 27 Feb 84 08:32:01-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  24 Feb 84 23:16 EST
Date:     Fri, 24 Feb 84 23:07:51 EST
From:     Keith Petersen <w8sdz@brl>
To:       Info-Cpm@brl
Subject:  MDM724 file list

This is a list of the MDM724 files uploaded to SIMTEL20 and MIT-MC.
All .COM files are stored in ITS-binary format on both hosts.

On MIT-MC         On SIMTEL20
AR100:FJW;     MICRO:<CPM.MODEM7>   (directory names)

M7LIB  COM         M7LIB.COM   (this is version 1.1 on both hosts)
M7LIB  DOC         M7LIB.DOC
M7LIB  HEX         M7LIB.HEX
M7NM   6ASM        M7NM-6.ASM
MDM724 ASM         MDM724.ASM
MDM724 COM         MDM724.COM
MDM724 HEX         MDM724.HEX
MDM724 MSG         MDM724.MSG
MDM724 UPD         MDM724.MSG
MDMFNK 11COM       MDMFNK11.COM
MDMFNK 11HEX       MDMFNK11.HEX
MDMFNK DOC         MDMFNK.DOC

--end--
27-Feb-84 08:32:09-MST,1070;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 27 Feb 84 08:32:02-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  25 Feb 84 1:26 EST
Received: From Mit-Xx.ARPA by BRL via smtp;  25 Feb 84 1:16 EST
Date: Sat 25 Feb 84 01:18:06-EST
From: Andrew Braunstein <OA.ASB@MIT-XX.ARPA>
Subject: Alternate Rainbow printers
To: INFO-CPM@BRL.ARPA
cc: .@MIT-XX.ARPA

   According to the Rainbow manual (or what there is of it), the rainbow's
printer port should respond to either an XON/XOFF protocol, or a DTR ready
signal on pin 6? of the rs232c connector.  The rainbow does not seem to
respond in any manner to the DTR signal being pulled HIGH or LOW on pin 6
or on pin 20 (where it should be).  The owners manual says on the bottom
of page 40 that "the printers DTR signal (on pin 6) has a higher priority
than XON/XOFF control characters (on pin 3)."

  If any one knows the fix to this problem, or can help in any other way to
make the rainbow respond to a DTR signal, it would appreciate it.
-------
27-Feb-84 09:28:37-MST,960;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 27 Feb 84 09:28:30-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  27 Feb 84 11:03 EST
Received: From Nadc.ARPA by BRL via smtp;  27 Feb 84 10:52 EST
Date: 27 Feb 1984 10:49:02-EST
From: reece@nadc
To: info-cpm@brl
Subject: modem7 on Micro Decision

I have been trying to get modem7 working on a Morrow Micro-Decision
and am having trouble. I was about to give up and out of desperation,
tried an older version (711) and it worked! Does anyone know why
711 would work and 720 would not? I have the newest MD3 model with the
software setable baud rates and a Centronics port. I made all the setup
routines in the overlay file just "return". I use the Morrow-supplied
setup program to change the rate and have the modem program assume
it's ready to use. I use the same modem720 program on an H89 and it
works fine.

Jim Reece
REECE@NADC
27-Feb-84 14:22:46-MST,825;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 27 Feb 84 14:22:40-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  27 Feb 84 16:01 EST
Received: From Sumex-Aim.ARPA by BRL via smtp;  27 Feb 84 15:59 EST
Received: from ISL by SUMEX-AIM with Pup; Mon 27 Feb 84 12:58:38-PST
Date: Monday, 27 Feb 1984 12:59-PST
To: info-cpm@brl
Subject: Disk Editor?
From: meier%isl@BRL.ARPA

	Does anyone know of a disk editor available for cpm and the 1791 disk
controller chip?  The following features are needed:
	o ability to read a bad sector in order to find out what is wrong
		or recover as much information as possible
	o ability to correct a bad sector
Please send your response to info-cpm rather than to me personally.
				Thanks,
				Bob (isl!meier@shasta)
28-Feb-84 08:10:09-MST,993;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 28 Feb 84 08:09:54-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  27 Feb 84 21:41 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  27 Feb 84 21:39 EST
Date: 27 February 1984 21:21-EST
From: Eric Stork <STORK@mit-mc>
Subject: Problem with MDM720 on MicroDecision
To: reece@nadc
cc: STORK@mit-mc, info-cpm@brl

Your experience with getting MDM711 to work on your machine, but not
MDM720, may be related to the overlay.  For MDM724 the overlay no
longer seems to work beyond the LOGON lable (I got it to work by
deleting everything that did not seem to match after examing
the first bytes and the overlay with DDT).  But I checked the PMMI overlay,
which may not be exactly like your MD version.
I don;t know if the problem goes back to 720.  If you like, I can send
you a copy of the overlay that now works for me, so you can examine it.
Advise if you want that.
Eric

28-Feb-84 08:10:23-MST,2614;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 28 Feb 84 08:10:09-MST
Date:     Mon, 27 Feb 84 22:25:29 EST
From:     David Towson (CSD) <towson@amsaa>
To:       info-cpm@amsaa
Subject:  Query to Multics people.

Multics people - I have been having an interesting exchange of messages with
David Cargo at Hi-Multics concerning the transfer of Simtel20 files stored in
ITS binary format (this includes all binary files, and ALL files in the SIGM
and CPMUG archives).  Apparently, Hi-Multics' FTP doesn't accommodate TENEX mode
(which works so nicely for us here on the BRLNET UNIX machines).  That has left
David in the same awkward position we were in until we were told about TENEX
mode, namely, that of having to transfer the files using binary mode, and then
post-process them to get rid of the four padding zeros that follow the four
8-bit bytes in each 36-bit ITS binary word.  With the aid of a system wizard,
David now has a program that is a modified version of a proprietary system copy
routine, and which does the necessary post-processing.  Using this program, he
has successfully transferred ITS binary files from Simtel20.  He has then used
Keith Petersen's ITSCVT program (available as ITSCVT.HEX on Simtel20 in 
directory MICRO:<CPM.HEX>) to remove the four ITS "header-bytes".  (This is 
done after the program has been downloaded to a CP/M machine.)
     So my question to you Multics users is this:  What methods are you using
to transfer ITS binary files from Simtel20 ?  Does anyone have an FTP that will
transfer these files and automatically discard the padding bits ?  Or is there
an FTP option that has not been mentioned here, and which will do the job ?
     As the maintainer for this list, I get many queries.  By far, the most
frequent questions deal with the archives and how to FTP.  Not being a Multics
user, I am very much at a disadvantage in trying to help Multics people, and I
would greatly appreciate your assistance in providing me with information.  
The program David is now using is based on proprietary roots, and cannot,
therefore, be freely distributed.  He has suggested the possibility of creating
a difference file that could be used by legitimate users of the base-program
to produce the modified version.  Back before we learned about TENEX mode
(which solved our problem on the UNIX machines), we too used a post-processor.
It was a happy day when we were able to abandon it.  Is there a similar happy
solution for Multics users ?



Dave Towson
info-cpm-request@amsaa


28-Feb-84 08:10:33-MST,997;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 28 Feb 84 08:10:26-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  27 Feb 84 22:57 EST
Received: From Parc-Maxc.ARPA by BRL via smtp;  27 Feb 84 22:44 EST
From: ssalzman.es@PARC-MAXC.ARPA
Date: 27 Feb 84 19:42:50 PST
Subject: Re: modem7 on Micro Decision
In-reply-to: reece@nadc.ARPA's message of 27 Feb 84 10:49:02 EST
To: reece@nadc.ARPA
cc: info-cpm@brl.ARPA

Hi. A friend of mine has an MD-3 and he's running mdm720 with no
problems. You shouldn't change anything in the overlay file at all.
Just leave all the port equates and modem setup routines in tack.
Run setup and make sure the serial port is set to 1200 baud. From there 
mdm720 will use a divisor to get down to 300 baud. Any more problems
let me know. We are in the process of getting the BYE program running
on it too. If you have anything on that let me know.

			- Isaac Salzman.

ssalzman.es@parc-maxc
28-Feb-84 08:10:42-MST,919;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 28 Feb 84 08:10:36-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  27 Feb 84 23:08 EST
Received: From Bnl.ARPA by BRL via smtp;  27 Feb 84 22:57 EST
Date: 27-Feb-84 22:00:34-EST
From: jalbers@bnl
To: STORK@mit-mc, info-cpm@brl, reece@nadc, root@BRL.ARPA

To: reece@nadc, root
Subject: Re:  Problem with MDM720 on MicroDecision
Cc: STORK@mit-mc, info-cpm@brl

I have discovered the same problem with the Osborne Executive and Osborne 1
overlays.  It looks like to overlays at SIMTEL20, or at least not all of them,
have been set up for MDM724+.  Is MDM724 larger than MDM720?  Should the
ORG or starting locations, or the locations of some 'subroutines' be changed
in the overlays?

                                            Jon Albers
                                            jalbers@bnl

28-Feb-84 08:10:43-MST,976;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 28 Feb 84 08:10:38-MST
Received: From Uw-Beaver.ARPA by AMSAA via smtp;  28 Feb 84 1:08 EST
Date: 27 Feb 84 22:00:22 PST (Mon)
From: David Ragozin <ENTROPY!rag@AMSAA.ARPA>
Received: by ENTROPY.UUCP (3.320/4.2)
	id AA29560; 27 Feb 84 22:00:22 PST (Mon)
Subject: Re:  Query to Multics people.
Message-Id: <8402280600.AA29560@ENTROPY.UUCP>
To: info-cpm@amsaa, uw-beaver!towson@amsaa

Some time ago someone posted the following suggestion for FTP'ing ITS
format files to get rid of thepadding bits in each 36-bit word:

>quote (> is the FTP prompt)
type "l 8"

Entering these two lines seems to set things up properly on the UNIX
system I work on, even though FTP does not have the 
TENEX mode (type?).

There is still the need to eliminate the first 4 bytes using ITCVT
(or using dd on a UNIX system).

Hope this helps.
David Ragozin - entropy!rag@uw-beaver
28-Feb-84 08:11:33-MST,1002;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 28 Feb 84 08:11:27-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  28 Feb 84 9:10 EST
Received: From Sri-Sprm.ARPA by BRL via smtp;  28 Feb 84 9:05 EST
Received: from Usenet.uucp by sri-unix.uucp with rs232; 28 Feb 84 5:55-PST
Date: 27 Feb 84 12:15:03-PST (Mon)
To: info-cpm@brl
From: hplabs!hpda!fortune!burton@ucb-vax
Subject: Moving Downloaded Files to Floppy - (nf)
Article-I.D.: fortune.2629

#N:fortune:25500007:000:409
fortune!burton    Feb 27 09:55:00 1984


For me this question is academic, since I'm not on ARPANET, and cannot down-
load from SIMTEL20.  For those who are/do, "How do you transfer your downloaded
files onto a floppy for use on your CP/M system"

  Philip Burton      101 Twin Dolphin Drive
  Fortune Systems    Redwood City, CA  94065	   (415) 595-8444 x 526
			- - -
{allegra  decvax!decwrl!amd70 cbosgd harpo hpda ihnp4 sri-unix}!fortune!burton
28-Feb-84 10:04:50-MST,815;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 28 Feb 84 10:04:45-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  28 Feb 84 11:44 EST
Received: From Mit-Mc.ARPA by BRL via smtp;  28 Feb 84 11:36 EST
Date: Tue, 28 Feb 84 11:22:54 EST
From: Manny Crivello <crivello@bbn-unix>
Subject: help wordstar
To: info-cpm@mit-mc

 Hi I have an: apple II+,als cpmplus,smarterm 80col, and pkaso interface to
a prism 132-all option. I can get Wordstar to work with my 80col or my
printer, BUT, not at the sane time. can anyone save me a lot time of debuging
and tell me how to configer wordstar.

p.s. i'm using wordstar ver 3.01p I also have ver 3.3.
      i would be greatful for any help.

                                         M.D.Crivello




28-Feb-84 11:51:18-MST,1075;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 28 Feb 84 11:51:07-MST
Date:     Tue, 28 Feb 84 13:33:06 EST
From:     David Towson (CSD) <towson@amsaa>
To:       hplabs!hpda!fortune!burton@ucb-vax
cc:       info-cpm@amsaa
Subject:  Re:  Moving Downloaded Files to Floppy - (nf)

Philip - There are two families of programs that are commonly used to download
files from a timeshare machine to a CP/M machine.  One is based on a protocol
created by Ward Christensen, and the other had its roots at Columbia University
(I think).  The first is called MODEM2, MODEM7, MDM7xx (xx=two digits) or some
similar name.  The second is called KERMIT.  Both of these are available for 
with several timeshare machines and many micros.  Whichever you choose, there
must be compatible programs running on both ends of the transfer to obtain the
benefits of automatic transfer with error detection and retransmission of bad
blocks.  MODEM7 files are on Simtel20, and KERMIT files are on Columbia-20.


Dave
towson@amsaa

28-Feb-84 15:57:15-MST,663;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 28 Feb 84 15:57:12-MST
Received: From Brl-Vgr.ARPA by AMSAA via smtp;  28 Feb 84 16:03 EST
Received: From Nbs-Sdc.ARPA by BRL-VGR via smtp;  28 Feb 84 15:58 EST
Date: Tue, 28 Feb 84 15:34:48 EST
From: blue@nbs-sdc
Subject: Aztec CII directed I/O
To: info-cpm@brl-vgr

Recently someone described the slowness of directed I/O with Aztec's
CII compiler as being caused by doing one 128-byte sector write for
each character written. Can someone point me to the way to fix this?
Thanks.
     Jim Blue
     National Bureau of Standards
     (blue @ nbs-sdc)
29-Feb-84 13:42:46-MST,1205;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 29 Feb 84 13:42:41-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  29 Feb 84 0:03 EST
Received: From Cmu-Cs-A.ARPA by BRL via smtp;  28 Feb 84 23:52 EST
Date: 28 Feb 84 2350 EST (Tuesday)
From: George.Wood@cmu-cs-a
To: info-cpm@brl
Subject: RE: disk editor wanted for cpm/1791
Message-Id: <28Feb84.235047.GW90@CMU-CS-A>


Ward Christiansen's DUU (DU version 77 ?)  is a good disk editor, but
will not do exactly what Bob Meier wants, i.e.  read a bad sector, if
the sector crc is bad; This is bacause the 179x series won't do the
read -- it reports the crc error instead.  If the sector is damaged but 
contains a valid crc, or is intermitently readable DUU will read it.

	The only way I know of to read really bad sectors is to read
the whole track and pick the sector out of the track.  I don't know of
any editor which will do this, although I have a little program which
will read a track into a buffer and let me mess with it via ddt.
Reading whole tracks is pretty hardware specific, and on some non-dma
systems, can't be done because of timing problems.

						George
29-Feb-84 13:42:52-MST,622;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 29 Feb 84 13:42:49-MST
Received: From Brl-Vgr.ARPA by AMSAA via smtp;  29 Feb 84 0:49 EST
Received: From Mit-Mc.ARPA by BRL-VGR via smtp;  29 Feb 84 0:46 EST
Date: Wed 29 Feb 84 00:43:45-EST
From: Lance Rips <HLP.LR%MIT-SPEECH@MIT-MC.ARPA>
Subject: Help on graphics
To: info-cpm@BRL-VGR.ARPA

     Does anyone know of reasonable graphics software
for cpm?  I don't need fancy pie charts or histograms,
but simply bivariate plots (with lines or just scatter)
for looking over data.  Thanks.        Lance
-------

29-Feb-84 13:43:00-MST,1402;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 29 Feb 84 13:42:55-MST
Received: From Hi-Multics.ARPA by AMSAA via smtp;  29 Feb 84 1:18 EST
Date:  29 February 1984 00:16 cst
From:  Eaton.HFED@hi-multics
Subject:  disk crc emulation
To:  info-cpm@amsaa

I am trying to duplicate the CRC generation that occurs inside a
WD1793 floppy disk controller chip.  Western Digital's application notes
on this chip specify that the crc register is preloaded with all ones and that
the crc generation commences with the address mark and continues through the
last data character.

The test data that I am attempting to use was obtained by reading
an ID field from disk.  It consists of:
       FE (ID Adr Mark),00,00,02,00,87 (CRC1),90 (CRC2).

I used the CRC routine from SYSLIB 2.7 feeding it 5 bytes of FE,00,00,02,00.
The result was not 87,90 as I felt it should be.  Even after modifying CRCCLR
to initialize it's counter to FFFF I was still unable to duplicate the CRC's that were generated by the WD1793.

Does the fact that the address mark is generated using a clock pattern of C7 have anything to do with this?  Are clock bits also piped through the generator?

The CRC routine supposedly uses the same X16 + X12 + X5 + 1 polynomial as
the WD1793 chip.

Where am I missing the boat on this?

          Eaton.HFED @ HI-MULTICS
29-Feb-84 13:43:12-MST,1749;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 29 Feb 84 13:43:04-MST
Received: From Hi-Multics.ARPA by AMSAA via smtp;  29 Feb 84 1:58 EST
Date:  29 February 1984 00:57 cst
From:  Eaton.HFED@hi-multics
Subject:  re:desoldering
To:  info-cpm@amsaa

Some desoldering techniques that I have heard of or used:

1. Hand held solder sucker ball and soldering iron. (pros are good with these)
2. Vaccuum pump with desoldering iron. (excellent and expensive)
3. Propane torch and chip puller. (used on surplus boards only)
4. Special multiprong tips which desolder all pins simultaneously.
5. Solder wick and soldering iron. (I always blow etches)
6. Clip pins off chip using GA54-2 cutters from Diamond Tools then
     trim leads on new chip and solder them to stubs from old chip.
     The cutters have carbide steel tips which actually crush the
     pins across their widest points.  A cheap tool will not hold
     up in repeated use.  As you can tell by the length of this entry
     this is my method of choice for replacing bad chips.  With the
     other methods that I can afford, there always seems to
     be some type of plated through hole damage.
7. One of my fellow technical types uses a variation of no. 6.  He takes a
     hammer and screwdriver, puts the board on a sturdy flat surface
     and smashes the little buggers to smithereens (the chips that is)
     then reuses the old leads just as before.  That always makes me
     nervous but he does it with high density memory boards with no
     ill effects.
8. Spring loaded vaccuum plungers and iron. (so-so)



That's all I can think of at the moment.  Bon Apetit.


	Jesse Eaton @ HI-MULTICS

29-Feb-84 13:43:23-MST,688;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 29 Feb 84 13:43:20-MST
Received: From Radc-Multics.ARPA by AMSAA via smtp;  29 Feb 84 10:31 EST
Date:  29 February 1984 10:32 est
From:  Wiedemann.4506i1808@radc-multics
Subject:  Ithaca S-100 CPU Monitor
To:  info-cpm@amsaa

     I have an Ithaca Audio Z-80 CPU board for an S-100 bus that needs a
monitor ROM.  The board is Model 1A-1010, Rev 2.
     Does anyone out there have the source code for the monitor?  I have
contacted Ithaca Audio and they said that since that board was
discontinued several years ago, they no longer support it.
     Thanx much!!

Wolf Wiedemann
29-Feb-84 13:43:31-MST,1245;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 29 Feb 84 13:43:26-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  29 Feb 84 11:21 EST
Received: From Usc-Eclb.ARPA by BRL via smtp;  29 Feb 84 11:18 EST
Date: 29 Feb 1984 0811-PST
From: Brad%fcdssasd@BRL.ARPA
Subject: Re: Help on graphics
Sender: FCDSSASD@USC-ECLB.ARPA
To: HLP.LR%MIT-SPEECH@MIT-MC.ARPA
cc: FCDSSASD@USC-ECLB.ARPA, INFO-CPM@BRL.ARPA
Reply-To: FCDSSASD@usc-eclb
In-Reply-To: Your message of 28-Feb-84 2336-PST

Lance,
    Probably the best all around grahpics package for business
applications or any fairly simple problem is a software package
called DGRAPH by FOX & GELLER 604 Market Street; Elmwood Park,
New Jersey 07407 phone (201) 837-0142

    Now i have used this package and it is very easy to use and
won't take any time to learn. It's all menu driven and will even
work on letter quality printers. In the latter use the period
wears out quickly. The final product looks good and as you can probably
tell, it will graph DBASE II (Ashton-Tate) files without conversion.

     Hope this helps. If you need mor info about DGRAPH (Fox & Geller)
then let me know.


Cheers,
Brad
-------
29-Feb-84 13:44:14-MST,712;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 29 Feb 84 13:44:10-MST
Received: From Hi-Multics.ARPA by AMSAA via smtp;  29 Feb 84 13:37 EST
Date:  29 February 1984 12:37 cst
From:  Cargo.PD@hi-multics
Subject:  ? Command line access from MBasic
To:  info-cpm@amsaa

I remember (too vaguely) seeing an article or note in a "recent"
publication (within the last year) a "how to" on getting the cp/m
command line from inside a MicroSoft BASIC program. I thought it was
either in Dr. Dobb's or BYTE, but it might have been Microsystems. I
would appreciate it if anybody could refresh my memory on this. Thank
you.
    David Cargo (Cargo at HI-Multics)
29-Feb-84 19:08:31-MST,972;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 29 Feb 84 19:08:27-MST
Received: From Brl-Vgr.ARPA by AMSAA via smtp;  29 Feb 84 20:51 EST
Received: From Mit-Mc.ARPA by BRL-VGR via smtp;  29 Feb 84 20:49 EST
Date: Wed 29 Feb 84 20:51:08-EST
From: Thomas D. Carrell <SR.CARRELL%MIT-SPEECH@MIT-MC.ARPA>
Subject: Help on graphics
To: hlp.lr%MIT-SPEECH@MIT-MC.ARPA
cc: info-cpm@BRL-VGR.ARPA

Another plotting package that I use a lot is DataPlotter available
from Lark Software, 7 Cedars Rd, Caldwell, NJ, 07006, phone
(201) 226-7552.  You can see examples of their plots in their
ads in Microsystems.  The package is cheap ($50), easy to use, flexible,
and the graphs look great.  I have had some accepted for
publication in professional journals.  They have versions for CP/M 80,
MS-DOS, and CP/M 86.  They support lots of different dot-matrix
printers, and you have to specify which one you want.
-------

